Core Domain Patterns
Time and resources are limited. How we spend our time and apply our resources when developing software systems is possibly the most fundamental and difficult challenge. Of all the things we could be doing, what should we do and how much quality and rigour should we invest?
A natural tendency for software engineers is to gravitate towards the most technically interesting challenges. I can confirm from my own personal experiences, although it’s not always the case.
Developers who follow a Domain-Driven Design approach, however, have a counter-balance. A concept known as the Core Domain. The Core Domain(s) are parts of the system with the highest return on investment for the business.
As developers, we should seek out the Core Domains to help us focus on delivering the biggest impact and not being drawn to technically-interesting but low-ROI features.
Core Domains are accompanied by Supporting Domains and Generic Domains. Supporting Domains are business necessities, they contain business concepts related to the domain, but there is limited ROI. Generic Domains represent concepts not-unique to our domain, such as user identity, sending emails, taking payments — we should consider buying SaaS or using open source instead of building Generic Domains.
In my attempts to bring clarity, structure, and quantification to these concepts so that they are easier to understand and apply, I’ve been using the following basic visualisation.
According to this definition, a Core Domain is an area of the domain with the opportunity for high business differentiation. This represents a compelling ROI. In addition, the implementation must have at-least a reasonable level of complexity (model complexity). If a simple forms over data (aka CRUD) solution will suffice, we shouldn’t waste time over-engineering.
Using this visualisation, we can go further and identify patterns which will guide our technology strategy and software development investments in the present and the future.
Decisive Core
When a core domain is extremely complex and offers maximum business differentiation potential, this is a decisive capability. Decisive because whichever organisation gets this right is likely to become market leader. The high levels of complexity necessitate that a big investment is required to triumph.
Short-term Core
When a core domain has high differentiation potential but complexity is relatively low, it may be a short-term core. Due to the low complexity, it’s not a defensible advantage and the competition will catch up in a relatively short time frame.
Hidden Core
A potential anti-pattern to be wary of is the hidden core. If a context has low complexity, a simple forms-over-data CRUD system, it’s not a core domain which requires us to innovate.
However, if this capability represents something which is differentiating for the business, we should be wary — either the competition will easily be able to gain parity or the business is missing a greater opportunity — for example, the complexity is still handled manually by employees and the software system is just replacing paper.
In this situation, the business should ask “Can we leverage the potential of technology here? Can we take manual processes and let computers do all of the hard work which people are currently doing?”.
Table Stakes Former Core
The natural lifecycle for any innovation is that over time it becomes table stakes — no longer an innovation that differentiates but still something that is needed.
Remember when the first wave of shops and restaurants began taking contactless payments? Wonderful, convenient, a reason which influenced where you chose to shop or dine. And now, we expect contactless payment everywhere.
Commoditised Core
Similar to the Table Stakes Former Core, even more drastically what was once a core domain can become a generic capability which any company can easily utilise as a SaaS product or an open source tool.
An example of a commoditised core is a search engine. If your product relied on advanced search capabilities to differentiate from the competition, the arrival of state-of-the-art open source and SaaS search engines like Elasticsearch would have destroyed your advantage, giving any potential competitor the capabilities to compete with you.
Black Swan Core
Sometimes the completely unexpected happens and an apparent commodity can become a core domain. The story of Slack comes to mind here.
Slack started life as internal chat system for a company in the video games market. When the video games failed to generate revenue the company decided to turn their chat system into a product. Slack is now worth $13 billion.
IRC was already an established chat standard which served a purpose. There appeared to be little differentiation potential. Nobody saw an opportunity, not even Slack and they were using the product.
Big Bet Core / Disruptive Core
For many initiatives, the potential level of business differentiation is unknown. Until the product is delivered and feedback from the market is acquired, nobody knows for sure.
Due to the potential being so high, potentially disrupting an industry, this type of capability can be a big bet because the organisation must inject significant resources and makes it a primary focus in the belief that the ROI could be enormous.
Suspect Supporting
If a bounded context is super complex yet is only supporting, serious questions should be asked. How can something with relatively little business differentiation require such high levels of investment to manage the complexity?
One completely valid reason is that accidental complexity is too high — perhaps a migration is in place from an old system to a new system. A clear plan and timeline for reducing the complexity should be in place to ensure the wasted effort can be re-allocated to capabilities with a higher differentiation potential.
Moving to the Next Level
I find assessing bounded contexts for business differentiation and complexity a very practical and approachable starting point. For teams who have little understanding of how their architecture connects to the business model, I’ve found this technique to be incredibly useful at enabling developers to reason more about the business perspective, and especially the evolution over time.
Give it it a try. Let me know your feedback and let me know of any other core domain patterns you discover. But don’t’ stop there…
To understand why capabilities evolve in differentiation and complexity over time, I highly recommend that you investigate Wardley Mapping and the Cynefin framework.
It’s also essential to understand the different types of complexity — essential vs accidental and the various sub-categories of accidental complexity.
