DEV Community

Discussion on: My DDD journey

Collapse
alexeyzimarev profile image
Alexey Zimarev

I believe that the aggregate pattern is still very useful. In the last chapter of my book (thanks Rafal for mentioning it) I used a functional approach, although with C#. Aggregates are implemented as a set functions expressing the behaviour and the state is an immutable record. The main thing about the aggregate pattern is that it's a consistency boundary and it doesn't really depend on the OO implementation.

Collapse
kspeakman profile image
Kasey Speakman • Edited on

I can totally see that.

We don't tend to use ARs, but achieve a similar effect (transaction boundary) with event streams. All use cases on the same event stream may not share the same model of state. For example, revoking an audit approval only needs to look through approve/revoke events and only needs to fold that into a state which keeps track of whether the audit is currently approved or not. Whereas other audit use use cases might examine all events from the same stream and replay into more detailed state. The dev can choose to share models between use cases. Having separate models for different use cases (on the same stream) is the standard DRY trade-off: repetition vs change isolation.

Thread Thread
alexeyzimarev profile image
Alexey Zimarev

Yeah, I agree. That's a stereotypical event sourcing in DDD style - having an event stream per aggregate. It's exactly how I am describing it in the book as well.