Guidance for engineering managers and other tech leaders on domain-driven design and how to deal with implementing it in your organization. If you are an IT/engineering manager, enterprise architect, development manager, or in any other capacity close to modern software engineering, this blog is for you. I wrote it a bit conversational, so it shows conversations I have in the field with peers.

What about the domain-anything lingo?

Domain-Driven Design, domain orientation, domain-driven development, or in short domain-driven are common expressions of a growing perspective on software engineering design. I call it a perspective because I think it's best explained as a way of looking. One could look at a large software system as a composition of semi-independent domains.

What is domain-driven and what does it look like?

Domain-Driven Design is a design style coined by Eric Evans in his famous book: Domain-Driven Design: Tackling Complexity in the Heart of Software. I’ll list more literature further at the end of the article. It's easier to tell why and how it's used than to use abstract definitions of what it is.

DDD is a high-level architecture style

For architects/designers, domains can be the most fundamental decomposition of your software ecosystems. For a retailer that can be domains like product catalog, purchasing, warehousing, etc.

DDD is a low-level implementation style and strategy

For developers, at its core, it provides a guideline on how systems could be engineered (the implementation style). An architecture pattern so to say. It provides a guideline to structure your development project up to the code level. One of the key concepts of this way of working is that it aims to capture the most complex business logic into a core ‘model’. Where a model can be seen as a programmatic abstraction. A good example would be the calculation module of a mortgage calculator.

The simplest way to express this style is that it focuses attention on core parts of your solution domain and puts them at the center of development with the least amount of boilerplate. Connectivity and other additions can be seen as peripheral connectors and adapters. A deployable service ships a core domain and the peripheral layer in order to deliver its value.

Additionally, DDD has a huge focus on the semantics of this core ‘model’ (implementation strategy). It prescribes to close the gap between how the business talks about its process and rules and our representation of them in our software.

When we zoom out on such a service, we will start to see the domain where its located. It will likely not be the only service. Ideally, you designate a team as the owner (to enable a DevOps ecosystem). The combination of services — so also teams — needs to be close together as well.

Why did domain-driven recently become popular?

Although around for twenty years, modern technical architecture (microservices/cloud), and socio-technical structures (DevOps/agile) are now aligned to allow for this way of building. Conversely, systemic changes like agile, DevOps, and cloud need a matching architecture strategy to make teams perform.

Some of these drivers required a new way of thinking that might also be happening for your teams.

• The increasing size of engineering teams requires division of work in a meaningful way (providing a creative and productive space)
• Teams have been pushed to deliver faster and more often, which pushes a desire for autonomy and decoupling from other teams.
• IT teams/companies have been ever-growing, creating more complicated platforms than ever before.
• Connectivity between systems exploded when individual services got smaller (microservices), and our capability to distribute software grew (cloud) causing a surge in complexity.

Should you promote domain-driven ideology in your firm?

This is THE big question. Let’s start with some downsides. It has costs. Domain-driven is not a simple switch. People will need to be educated, get convinced, and get experienced, and it’s a learning journey (which is usually a bumpy road). You will likely need to do some organizational restructuring. Teams need to be re-aligned to the right domains and value streams. Afterward, you will need to align the architecture as well. We now know this will be an investment. Let's see what it brings to the table.

Domain-driven will cost you money. But the question would always be: ‘will ignoring domain-driven cost you more money?’.

When you are faced with scaling or delivery issues, domain-driven can certainly be an agent of positive change. There are some other positive threats that I found many organizations and engineers to enjoy.

• DDD does not only help to create software. It will help you to structure the organization and guide you to create independent departments and teams as well. It's the best functional cookie-cutter I know to slice and dice your organization. I know a lot of managers that have big questions on how to properly divide the work over teams. We all know of centralized teams that cannot serve their demand, and feature teams that have so many dependencies, they can hardly get new stuff to their customers.
• DDD scales to enterprise levels. Scaled to dozens of teams, you are likely to still be better of in a design based on DDD. So consider it as a growth enabler similar to your other investments. If management would spend only a fraction of their energy on this decision as they do on selecting cloud vendors and recoursing partners, we would prevent a lot of pain.
• DDD will make creating facilitating teams that enable feature teams easier. Whether these are enabling teams, platform teams, or specialists on complicated components, many managers struggle with centralized versus decentralized teams and have difficulty in getting their team’s flow right.
• Our engineers face big technology shifts and rewrite increasingly more often. DDD puts your business to its core and decorates it with fancy technology (if you are interested in how you can read about hexagonal architecture). That makes for much easier rewrites to the latest and greatest message bus, API layer, or database technology.
• DDD makes your organization look good to candidates. Its shows you take engineering seriously. When the organization that you are working for is aligned properly to the business, it will provide a fruitful environment for successful software delivery. Autonomy, delivery speed, and properly managed dependencies provide for long and fruitful careers.

What things can feel unnatural in a domain-driven landscape?

With the rise of agile, we have put early delivery high-up on our wishlist. However, full DDD will concentrate a team's efforts on delivering a core model first. That core model will not look like a flashy App in the first rounds of demos. However, it will provide massive learning and faster iterations than you will ever get on a full cycle MVP iteration (frontend, backend). This can feel like we are not picking up the right speed. But bare with them. On projects with complicated domains, the pressure of delivering a shallow (but full cycle) iteration can be demanding on teams causing learning to slow down.

What are mistaken ideas on domain-driven that are common?

In DDD there is a lot of talk about ‘the model’. It provides a huge part of why DDD is relevant. However, I see people can misunderstand the model as being a data structure (like a relational model). However, the model has little to do with how the data is represented when stored. The model is code that represents the core business logic.

Also, domain-driven adoption should not need to be a black or white situation. I wrote a blog about domain orientation a while back, that discusses options to adopt mainly the high-level design concepts. Of course, it won’t get you the awesome benefits of code-level adoptions, but it's a great way to help you organize your IT landscape.

Where to go now?

There are some great resources out there. Reading the original works of Eric Evans is never easy but people consider the book ‘Domain-Driven Design Distilled’ by Vernon Vaughn a good first start. If you are in the data space, a popular new kid on the block is Data Mesh by Zhamak Dehghani which is influenced by DDD as well. The book Patterns, Principles, and Practices of Domain-Driven Design would maybe be a good next stop. And of course, you need to dive into the original work someday: Domain-Driven Design: Tackling Complexity in the Heart of Software.

Foremost I would recommend starting talking with your senior engineers. Some are bound to be influenced and even experienced with DDD by now.