Domain Types: Ownership is not random

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?

Recognizing domain types helps us with many decisions. We know what is the most important part of the system, we gain additional input when deciding what should be bought versus built in-house, and we can make better choices regarding the overall system structure.

Those are already significant benefits, but today I want to share another way domain types can support system development. This time, we will look at them from the perspective of team ownership and team assignments.

The same team structure is not good for every domain

Many organizations do their best to keep teams balanced. Every team has a similar seniority distribution, for example one experienced engineer, three regular engineers, and two junior developers (taking into account the natural fluctuations caused by rotations).

In theory, this sounds like a great solution. There is always someone who can guide others, and there is always someone in whom we invest.

In practice, the larger the system becomes, the less effective this approach tends to be. If subdomains differ in business complexity, strategic importance, codebase characteristics, and maintenance effort, different teams will naturally achieve different levels of effectiveness depending on their knowledge and experience.

The question is not whether teams should be balanced. The question is whether every domain requires the same balance.

Domain types - quick reminder

Just a quick reminder about the domain types we have:

• generic subdomain - ideally we integrate with an existing service or library. There is usually little code beyond the integration itself and the translation between our internal API and the provider's API.
• supporting subdomain - no existing service or library fulfills our needs, so we need to implement domain logic ourselves. These subdomains exist to support the core domain.
• core domain - the reason the system exists in the first place. This is where the organization creates an advantage over competitors and where most business-specific knowledge resides.

People in the team

The spectrum of knowledge and experience is huge, but for simplicity, let's use three levels:

• junior developer - someone at the beginning of their professional journey. They can work independently on straightforward tasks but still need guidance when dealing with complex business logic, architectural decisions, or unfamiliar problems.
• regular developer - someone who can independently deliver both business and technical functionality, including difficult tasks. However, when implementation decisions may significantly influence the future shape of the system, they still benefit from support and review from more experienced engineers.
• senior developer - someone who understands that every decision brings both value and cost and that no decision exists in isolation. They can evaluate trade-offs, understand long-term consequences, and shape solutions that support future system evolution.

One note though. When I write about senior developers, I also assume they understand the importance of code quality and testing. I'm not talking only about technical mastery. I'm talking about a deep understanding of why quality must be continuously maintained and what needs to be done to make it happen.

How to pick the team for a domain

How can we use this knowledge when assigning ownership? Let's go through the domain types one by one.

Generic subdomains

The code written here is usually not business-specific and, in many cases, can already be found somewhere on the Internet. Additionally, there is often relatively little code to maintain, which means even poor design decisions can usually be corrected without significant effort.

For those reasons, generic subdomains are good candidates for less experienced teams. The risk of making suboptimal design decisions is lower, and the resulting issues are usually easier to correct.

Supporting subdomains

Supporting subdomains require business-specific code. Since they exist to support core domains, engineers need more than technical skills. They must understand why business knowledge matters and how to connect that understanding with implementation decisions.

Supporting subdomains are a good fit for mid-level teams. They provide enough complexity to develop both technical and business skills while keeping the overall risk manageable.

Core domains

Core domains are where competitive advantage is created. They contain the most business-specific knowledge, evolve frequently, and often require deep collaboration with domain experts.

From an engineering perspective, this is where maintaining quality matters the most. Design decisions made here directly influence the team's ability to deliver new functionality quickly and safely over time. Performance, scalability, resilience, and maintainability are often more important here than in other parts of the system.

Core domains require engineers who combine technical expertise, quality awareness, and deep domain understanding. Senior engineers and experts are usually the best candidates to own them.

How to divide domains between teams

There are a few additional factors worth considering:

• in some systems there are more domains than teams
• some domains are modified rarely, while others evolve continuously
• teams should not become overwhelmed
• teams should have opportunities to learn and grow

This means the assignment is not as simple as:

• generic = juniors
• supporting = mids
• core = seniors

Such an approach would not end well.

Teams growth and health matters

Do not ask your most experienced team to own all core domains. They would quickly become overwhelmed.

Firstly, most changes will happen in core domains. Not because I say so, but because stakeholders see them as the most promising areas of the system, where competitive advantage can be created. Secondly, the changes themselves are rarely trivial. Much of the work requires more thinking than coding. Continuous refactoring of the domain implementation is essential. Maintaining the right language, establishing the right boundaries, and choosing the appropriate level of detail are difficult challenges on their own.

On the other hand, assigning all supporting domains to one team and all generic domains to another is not a great idea either.

Engineers want to learn. Teams grow over time. If you want to keep people motivated, you cannot only let them work on problems they already know how to solve. You also need to expose them to more challenging areas.

There is another risk as well.

If a team owns only generic subdomains, sooner or later some of its engineers may have very little meaningful work to do. Generic subdomains typically require relatively little business-specific development. After the initial implementation, the amount of new functionality added there is often limited.

Trying to compensate by continuously adding more features is usually not a good solution:

• generic subdomains are not the reason the system exists, so users rarely care about yet another fancy feature in this area
• more features mean more code, and more code means more complexity that somebody has to maintain
• the more functionality you add, the stronger your integration with the library or third-party solution becomes. While this can be managed, it introduces additional complexity and maintenance costs

So what should you do instead?

The numbers below are not rules. Think of them as a starting point for discussion. Every system has different constraints, priorities, and domain distributions.

The most experienced teams should own around 60-70% core domains. The remaining ownership can consist of supporting subdomains that provide variety and prevent the team from becoming overloaded with the most demanding parts of the system.

Mid-level teams could own:

• around 60% supporting subdomains
• 10-20% core domains so they can gradually learn how to work in more demanding business areas. Initially, these should not be critical parts of the system. This is where we want learning to happen in a relatively safe environment.
• 20-30% generic subdomains to occasionally work on less demanding problems and recharge their batteries

Less experienced teams could own:

• 60-70% generic subdomains
• 30-40% supporting subdomains

This allows them to work independently most of the time while still being exposed to challenges that help them grow.

Of course, these numbers will vary depending on the system itself. It may not always be possible to divide ownership this way. Still, I believe this is a reasonable starting point.

Domain interactions and similarities matter

Team experience and growth are important factors during ownership assignment. However, when dealing with larger systems, there are two additional variables worth considering:

• how domains interact with each other
• how similar their language is

When assigning multiple domains to the same team, it is worth looking at their interactions. The stronger the interaction, the stronger the argument for keeping those domains together. When a significant portion of the interactions is owned by a single team, extending those integrations becomes easier. Most discussions, agreements, and API decisions remain within the team instead of requiring cross-team coordination.

Another factor is the similarity of the language used within the domains. Keeping together domains that share concepts and vocabulary reduces cognitive load and makes development easier. It also helps engineers spot common problems and discover opportunities for extracting new domains in the future.

Ownership stability matters

Of course, our understanding of the system evolves over time. As domains mature, business priorities shift, and new knowledge emerges, it is worth revisiting ownership decisions and adjusting them when necessary.

However, ownership stability also has significant value.

Frequent ownership changes can destroy accumulated domain knowledge, weaken accountability, and increase coordination costs. Reassigning domains should therefore be an intentional decision driven by clear benefits, not a routine organizational activity.

Training Center example

Now let's take a look at the Training Center and the domains we discovered so far, and let's assume we have five teams: two experienced teams (A and B), two mid-level teams (C and D), and one less experienced team (E):

How could the assignment process look?

1. The two core domains, Education and Sales, do not appear to share much vocabulary and have limited interaction. We can assign Education to Team A and Sales to Team B.
2. Marketing seems to interact heavily with Sales and shares a significant amount of vocabulary. Assigning it to Team B makes sense.
3. CRM and HR are supporting subdomains. Based on what we know so far, they do not appear to have strong interactions with the core domains, nor do they share much vocabulary with them. They can be assigned to the intermediate teams.
4. Five generic subdomains remain. Earlier analysis suggests that Logistics and Calendar interact frequently, so we can keep them together and assign them to Team E.
5. GDPR and HR appear to share similar concerns and vocabulary, making Team C a reasonable choice.
6. Accounting will likely interact more with CRM than with Education, so assigning it to Team D seems reasonable.
7. The remaining generic subdomain, Archiving, can be assigned to Team B.

Conclusion

Domain types are useful for much more than deciding where to invest engineering effort. They can also help shape ownership strategies, team assignments, and growth paths.

Experience matters, but it should not be the only factor. Team growth, domain interactions, vocabulary consistency, ownership stability, and organizational constraints all influence the final decision.

There is no universal assignment formula. However, using domain types as one of the inputs allows organizations to make ownership decisions more intentionally and with a better understanding of the trade-offs involved.

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