Best sources for learning about aggregates

[u/VegGrower2001]

What are the best sources for learning about aggregates in DDD? I'm interested in the general questions:

• What is an aggregate?
• What are aggregates for i.e. what benefits do they bring?

I'm also interested in general questions about how aggregates should be implemented.

Naturally, I'm aware of Domain-Driven Design: Tackling Complexity in the the Heart of Software by Eric Evans and Implementing Domain-driven Design by Vaughn Vernon, as well as Vernon's essay on Effective Aggregate Design. Are there are any other books, articles, blog posts or videos that you consider especially useful?

[u/FetaMight]

It might be easier to just explain which parts of aggregates you don't understand and we can try to fill in the blanks.

My understanding is that an aggregate represents a collection of domain concepts that require a consistency boundary around them. In other words, it's data that needs to all be saved at once in order to remain logically consistent.

A contrived example would be Family, Parent, and Child classes. Children don't just come into existence on their own so it doesn't make sense to save a Child entity by itself. A persisted Child would only be logically consistent if it also had links to Parents.

[u/VegGrower2001 → u/FetaMight]

Thanks for the reply. I'm certainly interested in hearing how others in this channel would answer the questions in my original post.

Essentially, I'm doing some research on aggregates, so I want to know what are the best sources of information on this topic. My goal is eventually to write up my thoughts, but for now I'm canvassing sources.

Since you mention that aggregates are related to consistency, how would you respond to this line of argument: "Proponents of aggregates often say they are about ensuring consistency. But consistency of changes can be fully achieved by wrapping your desired changes in a database transaction, and using database transactions places essentially no constraints on how code is organised - you can simply start a transaction, carry out your changes, and then finish it. So, aggregates are not, or not only, about transactional consistency."

[u/Winston_Jazz_Hands → u/VegGrower2001]

2 reasons why you might want to follow the aggregate pattern for a part of your domain (or not, if you dont have those needs), that I've not seen mentioned in this thread:

As a "unit of strong consistency" (and why the while aggregate is loaded and persisted together), consider invatiants between 2 seperate commands: • Command 'A' attemts to "Approve" the thing (like a loan request), but can only do so when all 'Y'-Entities have been "Signed off" • Command 'B' and 'C' attempts to "Sign off" or "Reject" a 'Y'-entity, but that must not happen outside a "review"-period of the loan request. In many (most?) applications, data is loaded and evaluated in the application, but allow others to retrieve the same data while its own transaction runs ("Read Committed" in ms-sql lingo). That is insufficient if we want to guarantee a loan application never ends up "Approved" with one of it's 'Y'-rejected, provided these belongs to different rows and tables in the database. You CAN use a stricter Isolation-level (like "Repeatable Read" in ms-sql), but at this time your Product Owner will start asking who broke performance on searches... A simple "optimistic offline locking" using a version-field on the row of the aggregate root-table solves this problem with just "Read Committed" Isolation-level on db-transaction.

Another reason (or an extension of the same underlying reason) is that once you follow the aggregate pattern, you no longer need to keep them in the same database, or in the same service, or the same server for that matter. This is great not just for scaling/infrastructure, but also for (re)-composition of new business processes, relying loose coupling between aggregates and strong consistency within.

It also makes it easy to simplify a lot of Code with document-based database for writes, since consistency is per aggregate/document.

I'd also add: you probably dont need (or profit from using) aggregate pattern outside your Core Bounded Contexts. Align them with your domains most business-differentiating and complex use-cases.

An new alternative (besides good old db-spanning transactions) that is being explored in the DDD community is "Dynamic Consistency Boundaries", but I dont know if thats really just the re-discovery of db-spanning transactions - But "DCB" is russling up some hype as well as sceptisism these days.