Core, Supporting, Generic – How to Stop Treating All Domains the Same

Most businesses require knowledge from multiple domains to be successful. Some are essential due to the nature of the business itself, others are mandated by legal regulations and compliance obligations, and some exist simply to meet specific operational requirements.

After the last series of articles, you already know how to identify those domains. But what comes next? Once we define all domains, it’s worth categorizing them. This exercise helps us later make better software architecture decisions and organize teams more effectively.

Domain Types

Domain-Driven Design divides domains into three categories:

• Core domains

• Supporting subdomains

• Generic subdomains

This distinction highlights that domains differ in both complexity and business importance.

Core Domains

Core domains are the primary reason we create a given solution in the first place. This is where we aim to gain an advantage over competitors — to be better, faster, or more efficient (whatever that means in a particular business context).
To identify your core domains, ask yourself:

• What is the main problem our application solves?

• What do we want to achieve by building this solution?

• Why should customers choose our solution over the competition?

• What do our customers get from us that they won’t get elsewhere — at least not with the same quality?

Generic Subdomains

These are all the areas of your business or application that are necessary but not differentiating. They don’t need to be better or different from what your competitors have. Ideally, you should buy or reuse existing, proven solutions instead of building them from scratch.

Supporting Subdomains

Supporting subdomains sit between core and generic domains. They contain requirements that cannot be fulfilled by existing software, so you must develop them yourself. However, they don’t directly create business advantage — they support your core domains in doing so.

Domain vs. Subdomain

In the categorization above, you might notice the use of the word domain for core, and subdomain for generic and supporting. To be precise, they’re all domains — areas of knowledge with their own boundaries and ubiquitous language.
The term subdomain is used next to generic and supporting categories to emphasize their lower business importance. The core domain and everything within its boundaries are the most crucial parts of your business. You should invest most of your time and energy in improving them so your competitive advantage grows over time.

(Sub)Domain Types Are Local

Categorization within your business, even if done correctly, is not universally valid. Something that is a generic subdomain for you (e.g., invoicing in a training center) might be a core domain for someone else (e.g., invoicing in an accounting system).
It gets more complex when the categorization differs within the same business. For example, in a training center, one group of stakeholders might want to compete with a rich offer and attractive pricing (making Sales the core domain), while another might aim to provide the best-quality training (Education domain).

How Many (Sub)Domains Can You Have?

You can have as many domains in each category as needed — there’s no strict limit.
There’s also no required minimum. If there are no generic or supporting subdomains, that’s perfectly fine, though it’s hard to imagine a project without at least one core domain.
Even in internal projects or those driven by regulatory needs rather than competition, there’s always a main reason for the project’s existence. Once you identify it, you’ve found your core domain(s).

(Sub)Domain Categories Can Change

Projects evolve, and so can your categorization:

• A generic subdomain can become supporting when you start adding more business-specific logic.

• A supporting domain can become generic if an external solution later fulfills your needs.

• A supporting domain can turn core if you discover it offers potential business advantage.

• A core domain can become supporting when your business model shifts and you stop investing in that area.

Can a generic domain become core, or vice versa? Over time — yes. Market changes force adaptation, and many companies have gone through such transformations. Rapid shifts are less likely but still possible, often triggered by major market disruptions that require fast and fundamental business adjustments.

Example: Training Center

Let’s revisit the domains we identified earlier.

The key question is: how can we differentiate ourselves from competitors? Where can we build our advantage?
In a real project, stakeholders must answer this question — it’s not a technical choice. Still, the answer will strongly influence our architectural decisions later.

In our example, we assume we want to offer the best-quality trainings on the market. They don’t have to be the cheapest, but customers should know they’re getting exceptional value for their money. Additionally, we want to help customers choose the best training for their needs — whether they are individuals or companies.
Based on this, both Education (high-quality training) and Sales (customer support in choosing) are our core domains.

Which areas can be covered by existing solutions?
From our analysis, GDPR, Archiving, Logistics, Calendar, and Accounting appear to be generic subdomains — we don’t need anything extraordinary there, so off-the-shelf products should suffice.

Finally, since our core domains are Education and Sales, it makes sense to classify Marketing, Customer Relationship Management, and Human Resources as supporting subdomains. We could validate whether external tools can help, but since our focus is on training quality (HR supporting skilled trainers) and building great offers (Marketing and CRM), this classification makes sense.

Summary

Today, we identified and categorized the domains in our training center. We now understand which areas are most important and deserve our time, money, and attention — and which can be bought or outsourced without harming our business.

Next time, we’ll explore how this classification helps shape software architecture and team organization.
In the meantime, feel free to ask questions if you’d like to dive deeper into any aspect of domain types.