Aggregate Design: Using Invariants as a Guide

How do you compose an aggregate? For me, aggregate design involves understanding the invariants. Invariants are business rules that must always be consistent. Understanding the invariants will guide your aggregate design. Everything I seemingly post ends up being about defining boundaries! Aggregates are yet another example of defining boundaries based on invariants and consistency.

YouTube

Check out my YouTube channel where I post all kinds of content that accompanies my posts including this video showing everything that is in this post.

Shipment

The example I’m going to use is the concept of a Shipment. You could think of this as a food delivery service. You have food that gets picked up at a restaurant and delivered to your house. The shipment consists of 2 stops. The Pickup, which is the restaurant, and the Delivery which is your house.

Aggregate Design: Using Invariants as a Guide

The important aspect about a stop is they have to go through a state transition. The initial state of a stop is In Transit. Once the delivery person arrives at the restaurant to pick up the food, the stop then enters the Arrived state. Once the delivery person leaves the restaurant with the food and on their way to your house, the stop is now in a Departed state.

Invariants

There are a couple of invariants within our shipment.

  1. A stop must progress through its state transitions in the exact order outlined above.
  2. The delivery stop cannot arrive until the pickup stop has departed

The first invariant is fairly easy to control as we can have that logic within the stop itself.

The second invariant that the delivery stop cannot arrive until the pickup start is departed is a bit more difficult.

The issue is that an individual stop does not know about the other stops. Meaning the pickup stop object has no access to the delivery stop object. This is where an aggregate comes in.

Aggregates

An aggregate is a collection of domain objects that form a consistency boundary.

Our aggregate consists of the Shipment and Pickup and Delivery Stops. The Shipment is what is called the Aggregate Root.

The aggregate root is the gateway to all interactions within the aggregate. In other words, you only expose the aggregate root. The calling code cannot access Stops directly. Because of this, you can enforce invariants for the entire aggregate.

In the Arrive() method, we confirming that all prior Stops have been departed. This enforces that the Stops are done in the correct order. Meaning that the Pickup stop is going through its full state progression before we can start the state progression of the Delivery.

Aggregate Design: Invariants

Use invariants as the guide to designing your aggregates. Invariants are business rules that must always be consistent. If you have invariants and are not using an aggregate, I recommend modeling it to try it out for yourself. You’ll have fewer wonders about how the state changed because all interactions must go through the aggregate root. There’s only one-way state can change.

Source Code

Developer-level members of my CodeOpinion YouTube channel get access to the full source for the working demo application available in a git repo. Check out the membership for more info.

Additional Related Posts

Follow @CodeOpinion on Twitter

Software Architeture & Design

Get all my latest YouTube Vidoes and Blog Posts on Software Architecture & Design

Explore DDD 2017 Review

I just returned from Denver, Colorado, where the first Explore DDD conference was held.  I originally heard about it earlier in the year on Twitter via the organizer Paul Rayner and decided to submit a couple abstracts for the CFP.

Fat Controller CQRS Diet

The talk that was accepted and which I delivered on Friday morning was my Fat Controller CQRS Diet talk.  The talk revolves around trying to decouple your application from top I/O layer or framework.  More info on the talk can be found in my series of blog posts as well as a episode of Software Engineering Daily podcast.

Domain Driven Design

I stumbled upon Domain Driven Design somewhere around 2010.  I actually found it because of watching a talk online from Greg Young making some indirect references to Domain Driven Design and CQRS.  The talk caught my interest and within no time I was captivated by DDD and CQRS.  I instantly went and purchased the book.  That was a very significant point in my software development career.

Explore DDD

The speaker lineup at this conference was simply incredible.  Eric Evans, Rebecca Wirfs-Brock and Ward Cunningham were the keynotes.  Crazy. I cannot really believe that I was chosen to speak at such a conference. Imposter Syndrome was maxed out to 11. It didn’t take too long to have some conversations at the conference to realize that I had different experiences and views that proved to be valuable.  This didn’t knock down the imposter syndrome completely, but definitely lowered it a just a tad.  On the other hand, the amount that I learned from discussions and talks were like no other conference.

Community/Family

This really summed it for me.  There was a real sense of community/family.  I can’t really put my finger on why that is but I have a few guesses.

Conference Space/Location

Incredible.  38th Floor of the Grand Hyatt, looking over downtown Denver.  The floor itself was broken down into 3 track rooms, general gathering room where food was served, as well as a unique blue track room.  The blue track was reserved for spontaneous modeling, discussions, problem solving, whatever.  I actually had several interesting discuss here and it was kind of a good place for the “hallway” track in some respects.

Paul Rayner

The conference kicked off on Wednesday evening with the keynote by Eric Evans.  Paul spoke to intro the conference as well as each day with some house keeping notes.  I felt the way Paul gave such a calm welcoming, really set a tone for the entire conference.

Thank You!

Hands down an awesome conference.   Thank you to Paul for organizing an incredible event and selecting my talk.  All the attendees and speakers (from all over the world!) for making it feel like a family. I highly recommend attending this next year.  I hope to see you there!

Domain Driven Design: “What” not “How”

Common LanguageMany years have past since Eric Evans release the blue book: Domain Driven Design.  A lot has changed over the years but I find the core ideas still hold very true.

In some ways, I think some of the concepts outlined are even more prevalent now than they have ever been.

Ubiquitous Language

The Ubiquitous Language is a shared language developed by the team.  The team is everyone working on the project: developers, domain experts, QA, BA.

Everyone on the team.

The ubiquitous language isn’t developed by the domain expert(s) alone.  If you have more than one domain expert, they may struggle with language between each other to define concepts.

Everyone apart of the team is building, growing and refining the language.

Language is critical to not only verbal communication but how it’s represented in the software we are writing.  It represents the concepts and terms specific to the core business domain we are trying to model.

All the expressions, nouns and verbs are what the team is formally defining with an ubiquitous language.

Bounded Context

Boundaries

One of my favorite concepts is of the bounded context.  Bounded context should be autonomous.

Meaning, a bounded context should be independent and self governing.

It defines a set of business capabilities within the domain and represents a conceptual boundary.

One way of determining where the boundaries lie is with the ubiquitous language.

If a term or phrase has a different meaning in another context, you may have discovered a boundary and therefor another bounded context.

“What”, not “How”

With the rise/hype of microservices, the concept of a bounded context continues to hold true.

How do functional languages impact domain driven design?  As I’m leaning F#, I’m not overly concerned about the “how”.

The important part modeling a domain for me is the verbs, not the state.  I do think that will translate well to a functional language.

Focusing on the what not the how is what makes Domain Driven Design still very important and applicable so many years later.