Member-only story
Domain-Driven Design: A Walkthrough of Building an Aggregate
A guided tour through the process of building an aggregate and some hints and tips to keep you on the straight and narrow
Before I grab my metaphorical tour operator hat and begin our treacherous expedition through the long and windy roads of DDD Land, a few words of warning:
- It will be challenging
- You will make mistakes — and lots of them!
- You will never look at an even seemingly simple software problem in the same way
Will the journey be worth the perils? Absolutely!
Unfortunately, I am not an official tour guide of DDD Land as you probably guessed. Structuring aggregates and their boundaries are probably one of the hardest problems you will face in software development and bad news… there are no tour guides!
I’m still on my own journey with DDD and always trying to learn more, but here I offer a mental map of my thoughts when navigating my way through designing aggregates and testing them.
This article is aimed at people with some working knowledge of DDD and aggregates. If these concepts are new to you then a much better summary than I could muster can be found here by Jimmy Bogard. The examples use C#. However, if you are familiar with any OOO language then you will be able to follow.
Problem Domain
First, we need a problem domain to explore. In a previous article about domain and integration events, I created a small eCommerce app for a fake company, DDDMart. Let’s build on this by adding the concept of product reviews.
Business requirements
- Reviews must have an associated
OrderandCustomer. - Reviews must have a rating between 1–5.
- A comment must be left. It should be less than 200 characters.
- Customers can respond to reviews if they are less than six months old.
Subdomains
The domain is made up of three subdomains which are structured as independent microservices:
