There are no such things as Associations in DDD

I often see people trying to force-fit data relationships back into a Domain Model. Stackoverflow is full of questions about implementing associations in DDD.

But unfortunately, there are no such things as associations in DDD. When people talk about representing associations in Domain-driven Design, they are working backward - they are mapping data structures to domain concepts.

In this blog post, let us consider two examples to nail down the problem statement and walk through their representation in a domain model. But first, let's approach them with a naive CRUD/database structure point of view.

Users, Articles, Bookmarks: Authenticated users read articles and bookmark some of them for later review. If the user lands on an already bookmarked article, UI should indicate so.

An Application designer would typically model this requirement as three tables users, articles, and user_articles in a relational model. The last is a join table containing nothing but references to a user and an article. The association would be a has_many :through, a has_and_belongs_to_many, or a many_to_many association in Frameworks like Rails and Django.

Should the "Likes" of a user be stored as part of the User record in the a corresponding domain-driven model? Should each Article keep a list of users who have liked it?

Students, Classes, and Enrollments: Students in an Educational Institution can register to one or more classes, and a class can include many students. Enrollment is the primary mechanism of tracking Students for the school, including activity schedules, grades, and payments.

The structure would be similar to what we observed in the earlier example with students and classes tables in the relational model. But since an Enrollment seems to have a lifecycle of its own and many associated objects, there would probably be an enrollments table that would have references to the student and class records in addition to other attributes. The Enrollment will also have a unique identifier associated with it so that other objects, like Grades and Payments, can refer to it.

The domain-driven model would face a similar dilemma: Should enrollments be embedded under Students and Classes? Should Enrollment be treated as a separate Aggregate, and should version of it be stored under Student and Class aggregates?

Two DDD concepts can help us understand how to model these structures:

Aggregates are Transaction Boundaries

An aggregate is a cluster of associated objects considered as a single unit. All enclosed objects within the aggregate are loaded and persisted together, to be able to guarantee that Business Invariants are always satisfied.

If you have an aggregate that encloses a 1000 entities, you have to load all of them into memory. So it follows that Smaller Aggregates are better.

Aggregates are Cohesive Wholes

Put another way, Aggregates represent distinct concepts in the domain.

Behavior associated with more than one Aggregate (like Favoriting, in your case) is usually an aggregate by itself with its own set of attributes, domain objects, and behavior.

Let's add another obvious statement.

Things are far more straightforward in the DDD world.

I don't mean that as a platitude in any sense. After all, DDD's explicit goal is to tackle complexity head-on and simplify things as much as possible. Even with our threadbare examples, things are simplified by thinking in terms of domain concepts instead of table structures, as you will see.

In the first of modeling user bookmarks, Bookmarks are simply data points lacking any other annotation from a domain point of view. Remember, our workflow was to show that users already bookmarked an article if they land on the same item again. So the workflow demands that we know if the user has bookmarked an article. There seems to be no requirement to see the list of users who have bookmarked this article. Consequently, it is easiest to capture the bookmarked article's reference under the User Aggregate.

In the second case of modeling Enrollments, we are dealing with a full-fledged domain concept, with its own Entities, Value Objects, and Behavior. So it makes sense to model Enrollments as an Aggregate holding reference to the Student and Class it links. Aggregates expose intentions to change the state of the domain, and Enrollment will be no different; it will expose behavior methods and data attributes for use by the Application layer.

If there is ever a requirement to expose the list of enrollments under Students or Classes, we are only talking about showing data in a specific format consumption. Remember that Aggregate structures don't have anything to do with the underlying data structures.

Persistence Stores should not try to mirror Domain Concepts.

The only place in your application that should deal with databases is your Repository layer. Repositories should completely enclose a persistence store, and the application should be opaque to how the data is stored. If you were to use a design pattern like EventSourcing, there wouldn't even be data structures - just a bunch of events.

Architectural practices like CQRS shine when it comes to enforcing this separation. They segregate the write side from the read side, allowing flexibility in formatting data structures based on data consumption needs.

You can have infinite Read Models.

Domain Models are only for the "write" side of the application. Aggregates only deal with organizing data and enforcing constraints on the write side of the domain.

You are free to rewire the data any way you want, in multiple forms, on the read side. You can have a subscriber to listen to the Favorited Domain Events (raised after processing the Favorite Commands) and build a composite data structure containing data from both the User and the Ad aggregates.

If you need to send an API response in JSON format, one read model could hold already formatted, ready-to-transfer data. If you need the same data grouped differently for a business report, another read model will have the grouped data ready for use in a Business Analytics report. There is no limit to the number of data formats.

In conclusion, if you find yourself thinking about mapping an association in the Domain Model, stop and remember that you don't have to. You can have both the flexibility of designing the Domain Model to reflect the domain accurately and organize underlying structures in the most suitable format.