STOP doing dogmatic Domain Driven Design

The mainstream thought on Domain Driven Design is about Entities, Value Objects, Aggregates, Repositories, Services, Factories… all kinds of technical patterns. Because of this, most don’t think they need Domain Driven Design because it’s complicated for their domain. Why would you need all that “stuff”? Well, maybe you don’t! In a large system, modeling your domain, defining boundaries, and how they relate is far more important than concerning yourself if you’re using the Repository pattern correctly.


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.

Domain Driven Design

I often use terms that people associate with Domain Driven Design (DDD), however, I generally don’t call out Domain Driven Design explicitly in many of my videos or blog posts. You probably have noticed that I do talk a lot about boundaries. Boundaries are probably the most important aspect for me that came from Domain Driven Design. However, the vast majority of content or discussions you will find online about DDD revolve around tactical patterns: Entities, Value Objects, Repositories, Services, Aggregates, etc.

While the tactical patterns have value, they must come after understanding the concept and value of defining boundaries with a Bounded Context. While a Bounded Context does get a lot of attention from Domain Driven Design enthusiasts, it’s not what people are introduced to first in tutorials or “sample” applications.

Here are some of the comments and questions I see the most related to Domain Driven Design:

DDD is only powerful when your business logic is complex

While I agree complexity is a driving factor, I also think it’s helped me most when dealing with larger systems. Complexity from the Domain as well as the complexity that comes from a large system.

In DDD you’re supposed to use a repository pattern.

You need to use factories to create entities or value objects.

This is the wrong concern. Focusing on patterns rather than boundaries and modeling the actual domain.

You have no logic in your entities, so that’s an anemic domain model, which is an anti-pattern.

It’s only an anti-pattern if you think you have a domain model but you really have a data model with transaction scripts. There isn’t anything wrong with starting with that and moving to a richer domain model as your understanding of the problem evolves.

You can’t have dependencies in your Domain Model

People go to incredible lengths to avoid have dependencies in their domain model. While again it’s a good practice to avoid dependencies and worth striving for, sometimes you actually need a dependency. Using Double Dispatch isn’t bad because you’re passing a dependency to a method and someone told you all dependencies must be injected via the constructor.

Dogmatic Domain Driven Design

I think all the questions above are losing sight of the benefits of Domain Driven Design. I don’t think concerning yourself solely along with tactical patterns and if they are being applied correctly is applying DDD. I think that’s applying dogmatic DDD.

To me doing Domain Driven Design is about understanding your domain, the language, the context of different people within it, the problem, and the solution space and trying to model it. And you’re not going to get it right at first as it will take time to iteratively build upon the insights you gain.

There’s value in the tactical patterns like Aggregates (which are a consistency boundary), but that shouldn’t be the focus. Just because you have repositories, aggregates, entities, doesn’t mean you’re doing Domain Driven Design. You just have a bunch of patterns.


I find language a great way to understand the boundaries and define a bounded context within a system. A great example of this was from Mel Conway on Twitter.

Depending on who you’re talking to in your Domain, they likely have a different context given the subdomain they are in or the role that they have.

Exactly as Mel is pointing out, context matters in how language and intent is used.

As an example, in a Transportation company that transports freight/goods, there are multiple subdomains. Recruitment is who is hiring drivers, making sure they have the proper license, compliances, etc. Operations are concerned about the actual shipments and the freight being picked up and delivered.

Both have the concept of a Vehicle. But both have very different concerns and views on what a Vehicle is. They share the same term “Vehicle” but based on their context have very different views of what matters to me.

STOP doing dogmatic Domain Driven Design

In recruitment, the concept of a Vehicle maybe is owned by a Driver (known as an Owner Operator). They might care about the Vehicle Safety requirements and other compliances. Operations care about the availability of the vehicle and if it can do a particular shipment at a given time. Very different concerns.


Understanding a Domain, Subdomains, and developing a Bounded Context can be very challenging. I like to use the analogy of walking into a dark room with only a small flashlight

At first, you have no mental model of what the room actually looks like. As you slowly flash the light around the room, you get a better mental model of how high the ceilings are, what’s the shape of the room, what’s on the floor. Your understanding grows slowly as you shine the light.

Understanding the boundaries of a domain takes effort and is the key to being able to understand the problem and solution space. This is the key to domain modeling.

Domain Driven Design

The title says it all. It’s not pattern-driven design, it’s Domain Driven Design. Don’t get caught up in the dogmatic majority that is focused on the tactical patterns. Again, yes they are valuable. Aggregate Design is a great way to define consistency boundaries. I’m not discounting the patterns, but that’s not the focus. The patterns are a means to an end.

Source Code

Developer-level members of my CodeOpinion YouTube channel get access to the full source for any working demo application that I post on my blog or YouTube. Check out the membership for more info.

Related Posts

Follow @CodeOpinion on Twitter

Software Architecture & Design

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

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.


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.


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.


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.


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 Architecture & 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.


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!