BT

Designing and Storing Aggregates in Domain-Driven Design

| by Jan Stenberg Follow 37 Followers on Dec 11, 2014. Estimated reading time: 1 minute |

When working with Domain-Driven Design creating well designed aggregates is one of the least well understood patterns, Vaughn Vernon explains in two articles giving some guidelines for composing aggregate boundaries and alternatives to an ORM when storing them.

Vaughn, author of Implementing Domain-Driven Design, defines four rules that he believes will simplify aggregate composition:

  • Protect true invariants in consistency boundaries, which also imply that only one aggregate should be modified within a transaction.
  • Design small aggregates, with a single entity the smallest possible.
  • Reference other Aggregates only by identity, meaning you should not from one aggregate be able to directly access another aggregate.
  • Use eventual consistency outside the consistency boundary. One way of doing this is to use domain events to inform other parts, which in turn can initiate a separate update of an aggregate within a new transaction.

Vaughn strongly recommends a start with the second rule, letting each entity without exception become an aggregate root, then adding all fields or attributes needed for the aggregate to be created into a valid state.

Vaughn’s next step is to work with domain experts to find the aggregates that must be updated within the same transaction, and those that can be updated as a reaction to other updates. Here Vaughn warns for domain experts claiming that all entities have to be updated in the same transaction. This is very unlikely and probably more due to experts with experience from working with databased centric systems.

Searching for a better way than using an Object-Relational Mapping (ORM) framework for storing aggregates Vaughn has looked into serializing aggregates as JSON, then storing these in a document database. When working with domain events they must be stored within the same transactions as the aggregate update, otherwise a system may end up being inconsistent due to storage failures. A problem when using document databases is that most of them don’t support ACID transactions, in practice making them unusable in system where inconsistency is not acceptable. Instead Vaughn has looked for a data storage that supports transactions as well as JSON and one example he has found is a beta release of PostgreSQL 9.4 which he has used in a small example creating an aggregate storage.

Vaughn has also written a three part series about Effective Aggregate Design.

Julie Lerman earlier wrote about sharing data between bounded contexts.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Great article by Daniel Whittaker

One of the reasons people struggle with designing aggregates is that most of us in the development community are so used to thinking in data. Data-centric thinking or CRUD is so prevalent and ingrained that it is hard to break that mold. I know I keep seeing this question of inter aggregate communication coming up again and again. It is an indication that the design of the aggregate may not be right. It's like an early warning system. The trick is to know what to do about it. My first answer would be to pay attention to Vaughns suggestions for effective aggregate design. My next suggestion would be to take a look at danielwhittaker.me/2014/11/22/4-secrets-inter-a...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT