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.

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.

 

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.

Language

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.

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.

Discovery

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.