Domain types classification is part of the problem space. It increases our understanding of the business, its priorities, and its main aspects. On the other hand, it is not part of the implementation itself. However, this does not mean it lacks value — it still provides insights that help us make better, more informed software architecture decisions. Let's explore how domain classification can support us in this process.
Architecture Evolution
Today we will make a few initial decisions, but they may change later. To be honest, this is not a problem because:
every decision moves us forward
accepting the changes that will inevitably come forces us to design architecture in a way that supports evolution — a beneficial characteristic for any product we build
Build or Buy?
How can domain classification help us in the solution space?
First, by guiding us toward understanding which problems we should solve ourselves and where we should explore existing solutions. It’s important to emphasize that “buying” a solution does not have to be literal. It may be something already created and used within our company or an open‑source library. The key point is that it already exists and satisfies our expectations.
Generic Subdomains
Let’s start with generic subdomains. On their own, they can be quite complex. I don’t know anyone who would call Accounting simple. Yet we need these subdomains because they are required. They do not bring competitive advantage and, in most cases, we lack the domain expertise to understand them deeply. These are strong candidates for solutions worth buying. Problems from these domains can be solved in ways supported by their providers. It does not have to be implemented exactly as we would prefer. If the cost is acceptable and the features meet our needs, we can learn to use the existing solution.
From an architecture perspective, these external solutions may even remain outside of our direct interest due to minimal or manual integration with the system we implement.
Supporting Subdomains
Now let’s consider another category — supporting subdomains. Here, we should also look for solutions that already exist. However, in this case, we more often talk about services and tools that we will need to integrate with, even if we decide to acquire an external solution. This is simply because these subdomains support our core domains, which implies closer interaction.
Sometimes integration will not be enough, and we will need to add extensions crucial for the product we are building.
As you can see, coding within these subdomains is quite common. It might not be the most complex part from a business perspective, but it still requires development effort.
Core Domains
When we talk about core domains, we refer to areas where solutions must be built by us — especially where we seek competitive advantage. If that’s not the case, then perhaps our classification was inaccurate.
Build or Outsource?
Once we know what has to be built, we can move to the next question: what can be outsourced?
Generic Subdomains
If nothing suitable exists on the market, this becomes a good candidate for outsourcing. Perhaps there is already a company specializing in such solutions — use their expertise.
However, if no one provides it, maybe your classification was incorrect and you’ve discovered another core domain. Or a new product to build.
Supporting Subdomains
On one hand, this can also be a good candidate for outsourcing. After all, it’s not your core domain. On the other hand, you already know that domains evolve, and a supporting subdomain may eventually become a core domain.
Taking that into account, I recommend outsourcing only if the implementation focuses mostly on integration with another domain. If the supporting subdomain must be built from scratch or requires extending existing solutions, I suggest keeping the implementation in‑house. This ensures you maintain domain expertise and avoid creating a dependency on an external provider — especially important in case the subdomain evolves.
Core Domains
Core domains should be fully implemented by us. Since they represent the most important parts of our system, we must ensure domain expertise stays within the team. We don’t want to share this knowledge or rely on external vendors.
Decisions Can Be Changed
At this stage, we do not yet have full, deep understanding of the business, and some important aspects may still be outside our view. The more we learn, the more accurate our decisions become. This means decisions made now may change — and that’s perfectly fine. It’s better to move forward, adapt, and evolve than wait indefinitely for complete knowledge.
New information is not the only reason decisions might shift. When evaluating what we can buy, we may discover solutions we weren’t aware of before. Or we might assume something has the features we need but later find out it doesn’t. Or we expect the price to be acceptable but it turns out not to be. Additionally, something we built ourselves may later appear on the market as an off‑the‑shelf offering worth considering.
The market is not set in stone, so it is worth monitoring to stay informed and react when needed.
Summary
Domain types are not only a theoretical classification — they guide us toward better‑informed decisions. Thanks to this classification, it becomes easier to determine what to buy and what to build. It can even challenge our assumptions, especially if all our “core domains” turn out to be available on the market. But that’s not all. Using this classification, we can better manage risk and decide which aspects of the system are safe to outsource and which must stay with us — both in terms of domain expertise and implementation.
No comments:
Post a Comment