Domain Types: What if you build nothing? (Part 3)
Every architectural decision comes with a cost. Sometimes the most pragmatic solution is not another service, application, or vendor, but a simple manual process.
This article is part of the Strategic Domain-Driven Design: Domain Types series:
1. Domain Types: Identifying core, supporting, and generic domains (Part 1)
2. Domain Types: Build, buy, or outsource? (Part 2)
3. Domain Types: What if you build nothing? (Part 3)
Not every subdomain in a system needs to be built by internal teams. Some capabilities may be outsourced, and in some cases, you can simply buy an off-the-shelf solution.
Ideally, we want to address every problem in the problem space. Some solutions can be built, while others can be bought. Yet there is one more possibility - solving a given problem outside the system. The goal is not to ignore the problem, but to address it using a different approach than dedicated software.
A Subdomain Exists Even Without Software
From a strategic design perspective, it is important to remember that a subdomain exists regardless of whether we implement software for it. The business problem does not disappear simply because we decide not to automate it. The question is not whether the subdomain exists, but how we choose to address it.
The Cost of Solving a Problem
Building a new system and evolving an existing one is not an easy task. Every architectural decision comes with a cost. Part of our job is to ensure that we can sustain that cost and that we are willing to accept it. Sometimes, for various reasons, we cannot. In such situations, we may decide to keep the solution outside the system. This may mean initially handling the process manually, using simple tools such as spreadsheets, or postponing automation until the business can justify the investment. After all, the alternative may simply be too expensive.
Notice the word "initially." Choosing not to implement a capability today does not mean it will never be implemented. It simply means that, given the current business context, there are more important problems to solve first.
CRM in the Training Center
Let me use the Customer Relationship Management subdomain in our Training Center as an example. The fact that we may decide not to implement software for it does not make the subdomain disappear. Customer Relationship Management remains part of the business landscape. We still need to acquire customers, maintain relationships, and manage commitments. The only question is how we choose to support those activities.
Even though it is a supporting subdomain, we cannot afford to ignore the problems in this area. If we want to offer training sessions and enable people to attend them, we must manage relationships with our customers. Maybe we do not need to track everything from day one, but once any form of commitment starts, this becomes a must-have.
Additionally, we may work with other companies and try to convince them to use our training offerings. This is definitely something worth pursuing and managing as well.
Yet, if we are just launching the Training Center, we may decide neither to build a solution nor pay for an external service. Both options may be too expensive at the very beginning. In such a situation, we can agree with stakeholders or the client to track customer interactions initially using, for example, a spreadsheet.
Strategic Thinking, Tactical Decisions
Is that a good strategic solution for the long term? Definitely not. As the number of paying customers and prospects continues to grow, we will eventually need something dedicated to customer management rather than a simple spreadsheet.
However, as a tactical decision made within a specific business context, it may be a perfectly reasonable option for a limited period of time. It can become our deliberate choice. Thanks to that, we can save money or invest it in solving more important problems - the ones where dedicated software is essential.
Sometimes Not Automating Is the Right Choice
I'm not saying this is always possible, but I mention it to make you aware that it may be an option worth considering. Architecture is not only about code, boundaries, and hosting. To build a successful system, you also need to consider money, time, people, and their experience.
This is one of those situations where limited resources or a short deadline can become the primary factor. Under such circumstances, the best solution may be to address a subdomain outside the system for a period of time.
Strategic design is about making conscious choices. Sometimes the right choice is to build. Sometimes it is to buy. Sometimes it is to outsource. And sometimes the right choice is to deliberately postpone automation and solve the problem in a simpler way until business needs justify a different investment.
Continue the Strategic Domain-Driven Design: Domain Types series: [Previous]
Comments ()