CODEWITHSUNDEEP
domain-driven-designaggregateroot
Ivelin Matev
Ivelin Matev

Reputation: 382

DDD - Fictitious Aggregate Root

Sometimes I come to this case when I have a bunch of entity domain models which should be transactionally persisted but there is no logical domain model which could become an aggregate root of all these entity domain models.

Is it a good idea in these cases to have a fictitious aggregate root domain model which will have NO analogical database entity and will not be persisted in the database but will store in itself only logic for transactionally persisting entity domain models ?

P.S. I tought about that because having a database table storing only a single column of aggregate root ids seems wrong to me.

Upvotes: 3

Views: 620

Answers (2)

jlvaquero
jlvaquero

Reputation: 8785

An "aggregate root domain model which will have NO analogical database entity and will not be persisted in the database" is not a "fictitious aggregate"; it is a standard aggregate just like another aggregate that it needs to be persisted. The purpose of an aggregate is to control the changes following domain rules to ensure consistency and invariants.

Sometimes the aggregate is the change (and need to be persisted) but sometimes it is not and the things to be persisted after the change are parts/full entities and/or VOs that changed inside the aggregate and are mapped in persistence at its own without the needed of composing a persistence concept (table/s, document, etc). This is a implementation detail about how you decided to persist your domain data.

First premise of DDD: There is no DataBase. This helps you to not think too biased about trying to mapping persistence concepts in your domain.

Mike in his blog explain it better than me.

The purpose of our aggregate is to control change, not be the change. Yes, we have data there organized as Value Objects or Entity references but that’s because it’s the easiest and most maintainable way to enforce the business rules. We’re not interested in the state itself, we’re interested in ensuring that the intended changes respect the rules and for that we’re ‘borrowing’ the domain mindset i.e we look at things as if WE were part of the business.

An aggregate instance communicates that everything is ok for a specific business state change to happen. And, yes, we need to persist the busines state changes. But that doesn’t mean the aggregate itself needs to be persisted (a possible implementation detail). Remember that the aggregate is just a construct to organize business rules, it’s not a meant to be a representation of state.

So, if the aggregate is not the change itself, what is it? The change is expressed as one or more relevant Domain Events that are generated by the aggregate. And those need to be recorded (persisted) and applied (interpreted). When we apply an event we “process” the business implications of it. This means some value has changed or a business scenario can be triggered.

Upvotes: 4

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57249

Is it a good idea in these cases to have a fictitious aggregate root domain model which will have NO analogical database entity and will not be persisted in the database but will store in itself only logic for transactionally persisting entity domain models ?

Sort of.

It's perfectly fine to have a PurpleMonkeyDishwasher that joins together composes together the entities that make up your aggregate, so that you can be sure that your data remains consistent and satisfies your domain invariant.

But it's really suspicious that it doesn't have a name. That suggests that you don't really understand the problem that you are modeling.

It's the modeling equivalent of a code smell. There's probably a theme that arranges these entities to be modeled together, exclusive of the others, rather than in some other arrangement. There's probably a noun that your domain experts use when talking about these entities together. Go find it. That's part of the job.

Upvotes: 5

Related Questions