3
Focusing on the Core Domain
WHAT’S IN THIS CHAPTER?
- Why you should distill a large problem domain
- How to identify the core domain
- How to focus effort on the core domain
- The responsibilities of the supporting and generic domains
- Why not all parts of a system need to be well designed
It’s important to understand that not all parts of a problem are equal. Some parts of the application are more important than others. Some parts need more attention and investment than others to make the application a success. During knowledge crunching with domain experts, it’s important to reduce the noise of what’s unimportant to enable you to focus on what is important. Model-Driven Design is hard and should only be reserved to the areas of your systems that are vital to its success. This chapter covers how you can reveal the most important areas of a system and how by using distillation you can focus on those areas. With the knowledge of where to focus you can deeply model what is core, and focus on what will make a difference.
Why Decompose a Problem Domain?
Large systems built for complex problem domains will be made up of a combination of components and sub systems, all of which are essential to ensure the entire systems works. However some parts of the solution will be more valuable than others. It is essential therefore to focus effort and attention on the areas that are important to the business. You cannot equally spread effort and quality throughout the entire system, nor do you need to. Trying to strive for equality will result in a loss of focus on the real area that is essential to get right.
In order to understand the most valuable areas of a problem domain we need to distill it to reveal what is core. By breaking up the large problem domain we can more effectively resource the different areas to ensure the most talented developers are working in the areas of most importance to the business rather than the areas that may be more technically challenging or that utilize new frameworks of infrastructure. The subdomains distilled from the large problem domain are also an input to the way we will architect the solution.
How to Capture the Essence of the Problem
To know where to focus effort you need to understand what makes the application worth designing in the first place. You need to understand the business strategy and why the existence of the software you are creating will enable it. It is worth asking why the custom software is being written rather than opting for a commercial off-the-shelf product. How will building an application make a difference to the business? How does it fit within the strategy of the company? Why is it being built in-house rather than being outsourced? Does part of the software give the business a competitive edge?
Look Beyond Requirements
Be wary of business users asking for enhancements to existing software, because they will often give you requirements that are based on the constraints of the current systems rather than what they really desire. Ask yourself how often you have engaged with a user to really find the motivation behind a requirement. Have you understood the why behind the what? Once you share and understand the real needs of a customer, you can often present a better solution. Customers are usually surprised when you engage them like this, quickly followed by the classic line: “Oh, really? I didn’t know you could do that!” Remember: You are the enabler. Don’t blindly follow the user’s requirements. Business users may not be able to write effective features or effectively express goals. You must share and understand the underlying vision and be aware of what the business is trying to achieve so you can offer real business value.
Capture the Domain Vision for a Shared Understanding of What Is Core
Before embarking on any product engagement, always ask for a project overview. In any large organization, the process of project inception starts long before the development team gets involved. Often there will be a small paper on why the company wants to build the software for this initiative over another. This paper often holds the key to the core domain. The paper is a justification on why writing the software is a good idea; study this and pick out what is important. Make it explicit by writing the salient points on the whiteboard so all on the team understand why they are writing the software.
A domain vision statement can be created at the start of a project to explicitly capture what is central to the success of the software, what the business goal is, and where the value is. This message should be shared with the team and even stick it up on a wall in the office as a reminder to why the software is being written.
How to Focus on the Core Problem
Large problem domains can be partitioned into subdomains to manage complexity and to separate the important parts from the rest of the system. Figure 3.1 shows how in the domain of butchery, a pig is divided into cuts much like a problem space. Understanding the subdomains of your system enables you to break down the problem space. Subdomains are abstract concepts; don’t get subdomains confused with the organizational structure of a company. Subdomains represent areas of capability, define business processes, and represent the functionality of a system.
FIGURE 3.1 Cuts of a pig.
Try not to bring technical concerns into conversation when you are analyzing the problem space. Security is a technical concern unless your problem space is security. Audit trails and logging are also infrastructural concerns. Instead, keep focused on the domain first and foremost.
By distilling the problem domain you reduce complexity by dividing and conquering the problem. Smaller models can be created and understood within the context of a subdomain. This removes the need for a single large model to represent the entire problem domain. Many of these subdomains that are defined may be generic to any enterprise business software, such as reporting and notification needs. These subdomains, which do not define the application, are referred to as generic domains. The areas that distinguish your company’s unique product offering from a rival’s and define what gives it a competitive edge in the market are known as your core domains. The core domains are the reason why you are writing this software yourself. The remainder of the subdomains that make up large-scale applications are known as supporting domains, which are enablers for the core domain and the system.
Distilling a Problem Domain
Take the domain model of an online auction site, as shown in Figure 3.2. There are many different components that make up the large overall system. Some parts will be found in any online system, but some will be unique to the domain and specific business.
FIGURE 3.2 The domain of an online auction site.
Figure 3.3 shows how the large problem domain is partitioned into subdomains. Membership represents the area of the systems that deals with the registrations, preferences, and details of members. The seller partition represents all the processes and behaviors that deal with seller activities. Auction is the area of the problem domain that deals with managing the timing of auctions and dealing with bid activity. Listings are the catalogues of items that are available on the auction site. Finally, the dispute resolution domain deals with disputes between members and sellers.
FIGURE 3.3 The domain of an online auction site distilled into subdomains.
The distillation of knowledge after sessions with domain experts should reveal what’s unique and important about the application you are about to create. You can separate the subdomains into core, generic, and supporting domains, as shown in Figure 3.4.
FIGURE 3.4 The distilled domain of an online auction site partitioned into core, generic, and supporting domains.
In figure 3.4 you can see that the core domains of the online auction site are the seller and the auction. The seller domain contains the ratings for a seller and the domain logic for determining seller fees. The auction core domain is the mechanism for running an auction and handling bids. Both of these areas are vital for the success of the auction site. The membership and listing domains support the core domains by providing bidders the opportunity to create accounts and find items for sale. The dispute resolution domain is generic in that it can be served using a commercial off-the-shelf package; in this scenario it is merely a ticking system to handle customer dispute cases.
To know where to invest the most effort and quality, it’s crucial to understand where the core domains are, because these are key to making the software successful. This knowledge is distilled from knowledge-crunching sessions working in collaboration with domain experts to understand the most important aspect of the product under development.
Core Domains
To understand what’s core to the product that your business is asking you to develop, you need to ask yourself some questions. What are the parts of the product that will make it a success? Why are these parts of the system important? And why can’t they be bought off the shelf? In other words, what makes your system worth building?
The core parts of the system represent the fundamental competitive advantage that your company can gain through the delivery of this software. What’s core is not always obvious.
If the generic domains should be brought in and have little development, the core domain is the polar opposite. The core domains require your best developers—your commandos, if you will. The core domains may not make up the lion’s share of your company’s technology, but they require the most investment.
What is core certainly changes over time. If you are successful, competitors mimic, so the core domain must evolve to set your business apart from the rest and keep it ahead of the game. It’s vital that the development team take this on board and ensure it is in synergy with the values of the software and the business.
Treat Your Core Domain as a Product Rather Than a Project
One of the fundamental shifts in mentality required for writing software for complex core domains, from both the development team and the business, is to focus on the product rather than view it as a standalone project. Often, the development of software for a business product is never finished; instead, the product under development will live through periods of feature enhancements. The software is invested in until it is no longer providing value for the business or it can’t be enriched with further modifications.
Your product is an evolving succession of feature enhancements and tweaks. Just as developers iterate, so, too, does the business. A good idea becomes better after it is improved upon and fleshed out over time. Understand the value of the product you are working on and what return on investment (ROI) it brings to the company. Talk to your business sponsors about the future of the product to help focus your coding efforts; know what is important to them.
All too often, software for the core domain of a business isn’t viewed as a product that requires care and attention. Instead, business software sacrifices quality and long-term investment for speed to market. Too much emphasis is placed on thinking about the project and looming deadlines, rather than investing in the product for the future. This results in a codebase that is hard to maintain and enhance, and falls into the architectural pattern of the Big Ball of Mud (BBoM), as discussed in Chapter 1, “What Is Domain-Driven Design?”
The flip side, however, is a prolonged release date, which is often nonnegotiable if other business interests depend on the launch date of the software. The solution to this quandary is to look to descope features to keep quality high and the deadline on track. To be in a position to do this, you must understand and share the vision and ultimate goal that the software is expected to meet. This understanding enables you to include only the most important features of the product and ensure that it delivers the value the business expects.
Generic Domains
A generic domain is a subdomain that many large business systems have. An example of a generic domain is an e-mail sending service, an accounts package, or a report suite. These subdomains aren’t core to the business, but the business can’t operate without them. Because these subdomains aren’t core and won’t give you a competitive edge, it doesn’t make sense to spend a lot of effort or investment in building them. Instead, look to buy in software for generic domains. Alternatively, use junior developers to build these systems, freeing up more experienced resources to work on what’s core to your business.
Note, however, that a business defined by communication and targeted e-mails on limited-time offers, like a Groupon or a Wowcher, could have its core domain as a sophisticated e-mail/CRM system. What is core to one business may well be generic to another.
Supporting Domains
The remaining subdomains in the system are defined as the supporting domains. These are subdomains that, although not defining what your system does, help to support your core domains. For example, Amazon’s supporting domains would be the functionality that enables a customer to browse a catalog for products. Amazon’s product-browsing functionality doesn’t define it as a company, and neither is it that different from any other e-commerce site, but it does support the tracking of user journeys to feed a recommendations engine.
As with the generic domains, if possible, you should look to buy off-the-shelf solutions. Failing that, do not invest heavily in these systems; they need to work but do not require your prolonged attention. It’s important to note that you may not always need to implement a technical solution to a supporting domain. Perhaps a manual process could meet the needs of the business while developers focus on the core domain.
How Subdomains Shape a Solution
Within each subdomain a model can be created. Figure 3.5 shows how the online auction site has been divided into two physical applications. The dispute domain has been fulfilled by an off-the-shelf package while the core and supporting domains have been built using a custom web application.
FIGURE 3.5 How a solution maps to the subdomains of the auction system.
Not All Parts of a System Will Be Well Designed
Within each subdomain there will be a model that represents the domain logic and business rules that are relevant to that area of the system. Not all of these models will be of equal quality. With an understanding of the various subdomains that comprise your system you can apportion effort accordingly and apply the model-driven design patterns of DDD to the areas that will benefit most.
Don’t waste time and effort on refactoring all of your code—ensure your primary focus is on the core domain. If you end up with working but “messy code” for supporting and generic domains then leave it alone. Good is good enough. Leaving small silos of BBoM is fine as long as they are within clearly defined boundaries. Perfection is an illusion. Perfection should be reserved for only what is core. The business doesn’t care about quality code for areas that are required but are not key to the system and which are unlikely to be invested in over time.
Focus on Clean Boundaries Over Perfect Models
The Big Ball of Mud pattern is the most popular software architectural pattern. In large-scale software systems that have evolved over time there are more than likely areas of the system that are not perfect. If you have areas of an application that resemble the BBoM pattern then the best thing to do is to put a boundary around them to prevent the mud spreading into new areas of the application. Figure 3.6 shows the solution space of an application that has defined explicit boundaries between the legacy BBoM and the new models. An anti-corruption layer can be used to prevent one model blurring into another.
FIGURE 3.6 Dealing with legacy.
The Core Domain Doesn’t Always Have to Be Perfect the First Time
In an ideal world, quality software would always be top of your agenda; however, it’s important to be pragmatic. Sometimes a new system’s core domain could be first to market, or sometimes a business may not be able to tell if a particular idea will be successful and become core to its success. In this instance, the business wants to learn quickly and fail fast without putting in a lot of up-front effort.
The first version of a product that is not well understood by the business may not be well crafted. This is fine, because the business is unsure if it will be invested in over time, and the development team should understand why the business wants speed of delivery over supple design. However, if the product is a success and there is value in a prolonged investment in the software, you need to refactor to support the evolution; otherwise, the technical debt racked up in the rush to deliver starts to become an issue.
Build Subdomains for Replacement Rather Than Reuse
When developing models in subdomains try and build them in isolation with replacement in mind. Keep them separated from other models, legacy code, and third party services by using clean boundaries. By coding for replacement rather than reuse you can create good enough supporting subdomains without wasting effort on perfecting them. In the future they can be replaced by off-the-shelf solutions or can be rewritten as business needs change.
What If You Have No Core Domain?
There are many reasons that businesses build rather than buy software. If you can do it cheaper, faster, or smarter then it’s a good candidate for a custom build. If you find that the software you are building is all generic or is supporting other applications in your enterprise and therefore you have no core domain then don’t try and apply all of the practices and principles of DDD to your project. You can still benefit from following the strategic patterns of DDD but the Model-Driven Design tactical patterns could be wasted effort. You will learn more about when to and when not to apply the model-driven patterns of DDD in Chapter 9, “Common Problems for Teams Starting Out with Domain-Driven Design.”
The Salient Points
- Distillation is used to break down a large problem domain to discover the core, supporting, and generic domains.
- Distillation helps reduce complexity within the problem space.
- Focus and effort should be invested on the core domain. Use your best developers here.
- The core domain is the reason you are writing the software.
- Consider outsourcing, buying in, or putting juniors on the supporting and generic domains.
- A domain vision statement reveals a shared understanding of what is core to the success of a product. Use domain experts, project initiation documents, and business strategy presentations to help inform the domain vision statement.
- Plan to change the model within the core domain as you learn more about the problem. Don’t get too attached to a solution—your core domain may change over time.
- Not all of a system will be well designed. Focus effort on the core domain. For legacy BBoM systems define an anti-corruption boundary to avoid new code becoming tangled within the mess of old.