search

ddd-by-examples / library

A comprehensive Domain-Driven Design example with problem space strategic analysis and various tactical patterns.
MIT License
4.92k stars 726 forks source link

Aggregate domain model differences - Patron vs Book #35

Closed MateuszNaKodach closed 5 years ago

MateuszNaKodach commented 5 years ago

Hello, I've a question for concepts of implementing aggregates in your code. In the readme there is a statement:

our domain model may become immutable and just return events as results of invocking a command

And it's nice, but on the other hand Book aggregate looks quite different. The Patron aggregate state is modeled in one class, and the previous conception is easy acceptable in this situation. But the Book aggregate, as I see accepts events, and returns new states (in the future I see here opportunity for event sourcing with small effort). It's also OK, but why those two aggregates are modeled in different manners? And what about compensation process for event BookDuplicateHoldFound - it should be handled by Patron aggregate, shouldn't it? So in this case the Patron aggregate also ought to contains method which accepts event and return new state.

pilloPl commented 5 years ago

Hi! Thanks for asking. We modeled it differently just to showcase different modeling techniques. Actually you might say that Book is not an aggregate (does not protect any invariants - it's a downstream event listener).

Yes - it should be handled by someone - at least the hold should be taken off manually - because someone has listened to the BookDuplicateHoldFound event and sent an e-mail. That is thanks to loosely coupled design.