Domain-Driven Design: conclusion

When I decided to write about the basics of Domain-Driven Design, I thought I could capture the key concepts in two or three articles. In hindsight, I was a bit naive.

Domain-Driven Design is a huge topic, so there’s plenty to learn about. But that’s not all. The key concepts are closely interwoven. When I tried to explain just one concept, I realized that there were many others that needed an explanation first.

And so, what was supposed to be two or three articles turned out to be a full-blown series of ten. It’s time to wrap up and summarize what we have learned.

Domain-Driven Design is about teamwork

Gone are the days where software was made by only a few lone programmers. By now, software development has become so complex that it requires a diverse set of skills and close collaboration.

If we acknowledge this new reality, we should put teamwork front and center. We need to design our software in a way that it becomes accessible not just to software developers, but also to our colleagues from other fields.

This one change in our way of thinking alone can help our teams to accomplish more than we would have ever imagined.

Language plays an important role

Domain-Driven Design is fueled by a virtuous loop:

The more the members of a team work together, the more their language will align. A more aligned language will help the team to build a shared mental model. And a shared mental model will lead to more collaboration, thus closing the loop.

In my experience, the best way to enter this virtuous loop is to focus on collaboration, because humans automatically adjust their language to match that of their peers. What’s more, this is a simple change that we can make without the overhead of additional documents or processes.

Eventually, our team might arrive at a common language. When that language is used in all of the team’s communication, the language has essentially become ubiquitous.

Establish boundaries to scale beyond one team

Once you’ve tasted the benefits of a common language, you’ll probably want to take it beyond a single team.

Unfortunately, just because something works for a single team it doesn’t mean that it will work for a whole organization. Establishing and maintaining a common language is a lot of work: it requires everyone to stay in constant exchange with each other.

The only viable approach to scale Domain-Driven Design is the introduction of boundaries between teams. Give each team the opportunity to develop its own specialized language. Then introduce translation layers between the teams.

Explore, discover, refine

Experimentation plays an import role in Domain-Driven Design.

It’s unlikely that we’ll come up with the perfect domain model right from the start. Instead, we begin by building the smallest thing that will possibly work. Next, we collect feedback and then use it to improve what we’ve already got.

As a result, our team’s common language will continue to evolve and change. Changes are good, because they show us that we’ve learned something. On the other hand, changes carry the risk of eroding our shared mental model.

To apply Domain-Driven Design successfully, we need to make evolvability one of our top concerns. To that end, we’ve discussed five ways to facilitate change.

Turning ideas into code

Domain-Driven Design gives us a new goal for our software: it should be accessible to everyone on the team.

This is a lofty goal. Getting there requires a lot of experimentation. But how do we know if we’re making any progress? How can we tell if our design is any good?

We’ve learned that a good way to evaluate our code is by letting a developer explain it to a product manager. Code that is a direct representation of the team’s shared mental model should cause little confusion. But code that is packed with technical jargon will bring lots of confusion.

Finally, we practiced our new skills in a case study.

Where to go from here?

We’ve certainly covered a lot of ground over the past couple of weeks. If you’ve followed along, you might feel like an expert in Domain-Driven Design now.

But the truth is that we’ve only scratched the surface. There’s still so much more to learn. We haven’t even mentioned aspects like design patterns or design strategies yet.

If you’re excited to learn more about this topic, you should get the book that started it all: “Domain-Driven Design: Tackling Complexity in the Heart of Software” by Eric Evans.

The book is packed with wisdom about software development. It is one of these rare classics that you can read many times and discover something new each time.

If you’re looking for someone to join you on your learning journey, there’s a vibrant community of practitioners you can tap into.