3 ms·

I love that this focuses on event modeling as opposed to CQRS / Event Sourcing specifically. Those patterns are useful (CQRS and ES), and they imply a certain

I love that this focuses on event modeling as opposed to CQRS / Event Sourcing specifically. Those patterns are useful (CQRS and ES), and they imply a certain design, but event modeling and domain driven design are what really tie systems together. One thing I'm not sure I entirely agree with though is the flat cost of change. We've been working on an event modeled system for about 4 years now. It has grown in complexity and we've learnt a lot and we've invested a lot. At this point we are probably approaching a flat cost, but initially our cost increased quicker than a traditional project. There are a lot of pitfalls and learnings about building a system this way. Building read models gets very tiresome, and dealing with concurrency and idempotency are still hard (you just have a better tools / language for dealing with them). Having that, once you break the back of this and build the internal skills, it is a great way to work and I really believe the systems will scale much more easily (both in performance and feature capacity). It's worth realising the effort to get there is substantial tough.

eterps 7y ago
> Building read models gets very tiresome In what way does it get tiresome? In the increasing amount of read models needed?
- healsjnr1 7y ago
  That is one issue, as the number of services needing a model increases, you end up repeating this. It also becomes more complex as your domain grows and the complexity / number of events increases. Finally it can introduce a high degree of coupling, which ironically is something event modeling hopes to decrease. In this case if you have 5 or 6 consumers all building their own read model, but relying on specific events, the consumers are more deeply coupled into the services that emit these events. They now all need to be updated if something fundamental changes in the systems supplying events. I'm our case we used two techniques to mitigate this: - defined 'public' events with a clear api. These are the only events any external consumer should consume. Yes, it introduces some versioning ave migration issues, but also creates a clear and very helpful boundary. - defined read model as it's own domain and gave it a service. This is not always usable, but in many cases the model clients need of the entire system is fairly standard. This way they can integrate with a more typical query to pull the model rather than building it from scratch

eterps 7y ago

> Building read models gets very tiresome In what way does it get tiresome? In the increasing amount of read models needed?

healsjnr1 7y ago
That is one issue, as the number of services needing a model increases, you end up repeating this. It also becomes more complex as your domain grows and the complexity / number of events increases. Finally it can introduce a high degree of coupling, which ironically is something event modeling hopes to decrease. In this case if you have 5 or 6 consumers all building their own read model, but relying on specific events, the consumers are more deeply coupled into the services that emit these events. They now all need to be updated if something fundamental changes in the systems supplying events. I'm our case we used two techniques to mitigate this: - defined 'public' events with a clear api. These are the only events any external consumer should consume. Yes, it introduces some versioning ave migration issues, but also creates a clear and very helpful boundary. - defined read model as it's own domain and gave it a service. This is not always usable, but in many cases the model clients need of the entire system is fairly standard. This way they can integrate with a more typical query to pull the model rather than building it from scratch