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.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
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.
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.