1

Let's pretend I have an 'Book' entity, that can contain many 'Chapter' entities, having both their own unique IDs. A chapter must belong to a book, it cannot exists on its own (ie: there is a required foreign key in the chapter's table).

There is a screen where the chapter's content can be edited. So far, we considered books as aggregate roots, and everthing that was done on chapters was done through aggregates that had the parent book as root. All was great.

Suddenly, we get a requirement for the chapter editing screen, in which we need to add a dropdown list to be able of changing in which book we want the chapter to appear (from a list of account owned books), which breaks our current way of doing things.

How should I approach this? The application is SQL based, so being the relationship one-2-many, the operation is essentially changing the FK value in the chapter's table... but DDD wise, I believe it is more complex, since there may situations in which we need to update the book information (number of chapters, etc ... ). We work in transactional fashion, we cannot use eventual consistency for this.

  • Making a chapter an aggregate root itself?

  • Making a aggregate with a composite root between the current document and the one to where I want to assign the chapter to?

Thanks.

|improve this question
  • Your senario shouldnt cause any issues, simply remove the chapter from Book A and add it to Book B. – Ewan Jan 4 at 9:46
  • @Ewan: How do you ensure consistency if (database) transactions are at the level of the aggregate root (i.e. a single book)? I think that is the root of the question. – Bart van Ingen Schenau Jan 4 at 10:10
  • 1
    consistency is maintained, book.removeChapter(c); book.save(); book2.addChapter(c); book2.save(); – Ewan Jan 4 at 10:11
  • Why do database transactions need to operate at the same level as domain transactions? The idea of "one transaction per aggregate" is about maintaining domain consistency. I frequently see this concept misunderstood to apply to database transactions. Your database transactions are used to maintain application consistency. The only reason one should consider adopting one database transaction per aggregate is if you anticipate (i.e. need) the scaling benefits that eventual consistency can provide. – king-side-slide Jan 4 at 15:47
2

Traditionally, the recommendation has been to deal with cross-aggregate domain operations in a Domain Service.

It does mean making an exception to the "transaction per aggregate" rule, but since you mentioned "no eventual consistency", there's not a lot of other options.

Technically speaking, there is no obstacle to this since Domain Services are usually called from an Application Service that also controls the transactions. The Application Service can wrap the Domain Service call in a transaction just like it would do a call to an aggregate root method.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.