4 ms·

It's to do with the fact that the original implementors decided to apply this design pattern for the entire system, including places where it's not really usefu

by Yuioup 9y ago

It's to do with the fact that the original implementors decided to apply this design pattern for the entire system, including places where it's not really useful like CRUD. A lot of redundant plumbing in the code with classes mapped to other classes. The data structure they chose does not allow inheritance so there are a lot of classes that look exactly alike where sub-classes would be useful. This notion of Command that generates an Event that generates more Commands that can generates more Events asynchronously with code for eventual consistency. Lovely concept but database records don't exist. You can't just query a database. You have to build your views based on playing back your events. I just find it completely confusing. Frustrating as well because certain things that are trivial in an RDMS end up costing an incredible amount of development time in CQRS+Event Store. I must admit unfamiliarity with the architecture is definitely a factor - except that my predecessors wrote everything from scratch down to the JSON format of the data structure. One mistake and the microservices crash causing the data to be in an invalid state. In order to fix the data, you need to replay all the events - and there are millions of them. Nothing ever gets deleted because a 'delete' is a new event. pffff ....

UK-AL 9y ago
"you need to replay all the events" If your aggregates have millions of events, I would suggest snapshotting, or mementos.
deleted 9y ago
[deleted]
karmajunkie 9y ago
I don't blame you for being soured on it—sounds like there are a lot of antipatterns in play there! > including places where it's not really useful like CRUD. Probably the most common mistake made by architects doing it for the first time. > You can't just query a database. You have to build your views based on playing back your events. Its pretty common to have projections that build database tables so you can do exactly that. It sounds more like the original architects violated (or had poor delineation) of service boundaries, which just creates a tightly coupled set of microservices, which is worse than the monolithic architecture it seeks to replace. > In order to fix the data, you need to replay all the events - and there are millions of them. Nothing ever gets deleted because a 'delete' is a new event. Its also common to archive streams periodically and "declare bankruptcy" with an initial state setting event, proceeding forward from there. Snapshotting is also a thing. You might find this helpful in dealing with some of those issues: https://leanpub.com/esversioning/read#leanpub-auto-status https://leanpub.com/esversioning/read#leanpub-auto-status

by Yuioup 9y ago

UK-AL 9y ago

"you need to replay all the events" If your aggregates have millions of events, I would suggest snapshotting, or mementos.

deleted 9y ago

[deleted]

karmajunkie 9y ago

I don't blame you for being soured on it—sounds like there are a lot of antipatterns in play there! > including places where it's not really useful like CRUD. Probably the most common mistake made by architects doing it for the first time. > You can't just query a database. You have to build your views based on playing back your events. Its pretty common to have projections that build database tables so you can do exactly that. It sounds more like the original architects violated (or had poor delineation) of service boundaries, which just creates a tightly coupled set of microservices, which is worse than the monolithic architecture it seeks to replace. > In order to fix the data, you need to replay all the events - and there are millions of them. Nothing ever gets deleted because a 'delete' is a new event. Its also common to archive streams periodically and "declare bankruptcy" with an initial state setting event, proceeding forward from there. Snapshotting is also a thing. You might find this helpful in dealing with some of those issues: https://leanpub.com/esversioning/read#leanpub-auto-status https://leanpub.com/esversioning/read#leanpub-auto-status