Domain Types: Three Myths About Domain Types

This article stands on its own, but if you'd like to explore the topic further, it's part of the Strategic Domain-Driven Design: Domain Types series:
1. Identifying core, supporting, and generic domains
2. Build, buy, or outsource?
3. What if you build nothing?
4. The architecture your subdomain deserves
5. Ownership is not random
6. How much should you trust AI?
7. Three Myths About Domain Types

We spent some time exploring domain types, how to identify them, and how they can help us build software that is easier to maintain and evolve. Today, I want to walk you through a few common myths about domain types. If you know any others, don't hesitate to share them in the comments - I'd be happy to discuss them as well.

Myth 1: Domain boundaries are system boundaries

Many engineers want to start building something they can deploy as soon as possible, and I completely understand that. A working system always feels more valuable than a conceptual model. That's why many people assume that once they discover and establish domain boundaries, they already have the first draft of their system.

Yes and no.

By identifying domain boundaries, we learn what the system capabilities will be and what responsibilities belong within each boundary. We know which parts are more important and which are less critical. We identify where the most significant changes are likely to happen. We understand where one domain ends and another begins. We also know who we should talk to when we need more clarification or when changes become necessary. So yes, we learn a lot about the future system.

But why aren't we ready to jump straight into implementation?

Because there are still many important aspects we haven't considered. We explored the problems the system needs to solve, but we haven't yet thought about how it will support its users - whether they are humans, AI agents, or other systems. We still need to understand which existing services and solutions we must integrate with. We also have to consider security, scalability, operational concerns, and both internal and external integrations. All of these factors will influence the final implementation.

That said, I've mentioned many times during workshops that domain boundaries can serve as the first naive draft of your software architecture. I still stand by that statement. If you need to start implementation quickly because of deadlines or other constraints, using domain boundaries as a starting point is far better than starting with nothing.

There is, however, one important disclaimer: your system will evolve. That is not a mistake - it is simply how software development works. If you decide to use domain boundaries directly as service boundaries, there is a high probability that they will change relatively soon as your understanding of the solution grows.

Myth 2: Every domain must be implemented by us

This isn't about generic subdomains, which naturally rely on existing solutions. Instead, it's about parts of the problem where we deliberately decide to postpone the implementation or not implement it ourselves at all.

Domains belong to the problem space, which means they represent problems that need to be solved. However, solving those problems doesn't necessarily mean implementing them as part of the software we build. They don't have to become part of our system, they don't always require integration, and sometimes they don't even need to be solved with software at all.

This becomes much more obvious once you remind yourself that you're still working within the problem space. Despite that, I've seen many discussions where teams immediately jump into technical questions about integration technologies instead of deciding whether a software solution is needed in the first place.

The reality is that sometimes we deliberately choose one of the following approaches:

1. No software at all. Using our Training Center example, all logistics-related problems could be delegated to a company that specializes in logistics.
2. Software that we won't integrate with. For example, we may decide not to integrate with the Human Resources system responsible for hiring. Instead, someone can manually create an account in our system after the hiring process is completed.

There can be many reasons for making these decisions. Sometimes we postpone automation until the business grows. Sometimes it is simply a strategic decision to delegate solving a particular problem to someone else.

Myth 3: Only bounded contexts matter

This is probably the myth I've heard most often from engineers who are just starting their architecture journey. They want to follow proven practices and established approaches, but at the same time they are eager to solve technical problems immediately. Many developers have not yet experienced how strongly business understanding influences architecture and shapes the evolution of a system.

What happens if you skip domain discovery and focus on bounded contexts from the very beginning?

You'll still be in a much better position than someone who ignores boundaries altogether.

However, you'll miss several important insights:

• The priorities of different domains and their importance to the business. These factors heavily influence architectural and technical decisions.
• The parts of the business that are outside your system. They may not seem relevant at first, but understanding the complete set of business problems gives you much better insight into the solution your stakeholders are trying to achieve. That broader perspective often allows you to propose even better solutions. Sometimes your stakeholders aren't even aware of the technical possibilities available to them.

Summary

All three myths have the same root cause: treating domain types as a design tool instead of a learning tool.

Domain types are not about drawing service boundaries or making implementation decisions. They help us understand the business, identify priorities, and build a shared understanding of the problem space.

That understanding becomes the foundation for every architectural decision that follows. The better we understand the business before designing the solution, the easier it becomes to make sound technical choices, identify worthwhile trade-offs, and build software that can evolve together with changing business needs.

Continue the Strategic Domain-Driven Design: Domain Types series: [Previous]