Chapter 15: Distillation
- "Distillation is the process of separating the components of a mixture to extract the essence in a form that makes it more valuable and useful."
- "Strategic distillation of a domain model does all of the following:"
- "Aids all team members in grasping the overall design of the system and how it fits together"
- "Facilitates communication by identifying a core model of manageable size to enter the ubiquitous language"
- "Guides refactoring"
- "Focuses work on areas of the model with the most value"
- "Guides outsourcing, use of off-the-shelf components, and decisions about assignments"
- Core Domain
- "In designing a large system, there are so many contributing components, all complicated and all absolutely necessary to success, that the essence of the domain model, the real business asset, can be obscured and neglected."
- "The harsh reality is that not all parts of the design are going to be equally refined. Priorities must be set. To make the domain model an asset, the model’s critical core has to be sleek and fully leveraged to create application functionality. But scarce, highly skilled developers tend to gravitate to technical infrastructure or neatly definable domain problems that can be understood without specialized domain knowledge."
- "Boil the model down. Find the core domain and provide a
means of easily distinguishing it from the mass of supporting model
and code. Bring the most valuable and specialized concepts into
sharp relief. Make the core small.
Apply top talent to the core domain, and recruit accordingly. Spend the effort in the core to find a deep model and develop a supple design—sufficient to fulfill the vision of the system. Justify investment in any other part by how it supports the distilled core." - Choosing the Core
- "The core domain you choose depends on your point of view. For example, many applications need a generic model of money that could represent various currencies and their exchange rates and conversions. On the other hand, an application to support currency trading might need a more elaborate model of money, which would be considered part of the core. Even in such a case, there may be a part of the money model that is very generic. As insight into the domain deepens with experience, the distillation process can continue by separating the generic money concepts and retaining only the specialized aspects of the model in the core domain."
- "One application’s core domain is another application’s generic supporting component."
- Who Does the Work?
- "It is essential to [assemble] a team matching up a set of strong developers who have a long-term commitment and an interest in becoming repositories of domain knowledge with one or more domain experts who know the business deeply. Domain design is interesting, technically challenging work when approached seriously, and developers can be found who see it this way."
- An Escalation of Distillations
- Distillation techniques ordered by needed effort
- Domain Vision Statement
- Highlighted Core
- Generic Subdomains
- Cohesive Mechanisms
- Segregated Core
- Abstract Core
- Generic Subdomains
- "Some parts of the model add complexity without capturing or communicating specialized knowledge. Anything extraneous makes the core domain harder to discern and understand. The model clogs up with general principles everyone knows or details that belong to specialties which are not your primary focus but play a supporting role. Yet, however generic, these other elements are essential to the functioning of the system and the full expression of the model."
- "Identify cohesive subdomains that are not the motivation for
your project. Factor out generic models of these subdomains and
place them in separate modules. Leave no trace of your specialties
in them.
Once they have been separated, give their continuing development lower priority than the core domain, and avoid assigning your core developers to the tasks (because they will gain little domain knowledge from them). Also consider off-the-shelf solutions or published models for these generic subdomains." - Generic Doesn't Mean Reusable
- "Note that while I have emphasized the generic quality of these subdomains, I have not mentioned the reusability of code. Off-the-shelf solutions may or may not make sense for a particular situation, but assuming that you are implementing the code yourself, in-house or outsourced, you should specifically not concern yourself with the reusability of that code. This would go against the basic motivation of distillation: that you should be applying as much of your effort to the core domain as possible and investing in supporting generic subdomains only as necessary."
- Project Risk Management
- "Projects face risk from both sides, with some projects having greater technical risks and others greater domain modeling risks. The end-to-end system mitigates risk only to the extent that it is an embryonic version of the challenging parts of the actual system. It is easy to underestimate the domain modeling risk. It can take the form of unforeseen complexity, inadequate access to business experts, or gaps in key skills of the developers."
- "Therefore, except when the team has proven skills and the domain is very familiar, the first-cut system should be based on some part of the core domain, however simple."
- Domain Vision Statement
- "At the beginning of a project, the model usually doesn’t even exist, yet the need to focus its development is already there. In later stages of development, there is a need for an explanation of the value of the system that does not require an in-depth study of the model. Also, the critical aspects of the domain model may span multiple bounded contexts, but by definition these distinct models can’t be structured to show their common focus."
- "Write a short description (about one page) of the core domain and the value it will bring, the “value proposition.” Ignore those aspects that do not distinguish this domain model from others. Show how the domain model serves and balances diverse interests. Keep it narrow. Write this statement early and revise it as you gain new insight."
- Highlighted Core
- "Even though team members may know broadly what constitutes
the core domain, different people won’t pick out quite the same
elements, and even the same person won’t be consistent from one
day to the next. The mental labor of constantly filtering the model to
identify the key parts absorbs concentration better spent on design
thinking, and it requires comprehensive knowledge of the model.
The core domain must be made easier to see.
Significant structural changes to the code are the ideal way of identifying the core domain, but they are not always practical in the short term. In fact, such major code changes are difficult to undertake without the very view the team is lacking." - The Distillation Document
- "Often I create a separate document to describe and explain the core domain. It can be as simple as a list of the most essential conceptual objects. It can be a set of diagrams focused on those objects, showing their most critical relationships. It can walk through the fundamental interactions at an abstract level or by example. It can use UML class or sequence diagrams, nonstandard diagrams particular to the domain, carefully worded textual explanations, or combinations of these. A distillation document is not a complete design document. It is a minimalist entry point that delineates and explains the core and suggests reasons for closer scrutiny of particular pieces. The reader is given a broad view of how the pieces fit and guided to the appropriate part of the code for more details."
- The Flagged Core
- "Flag each element of the core domain within the primary repository of the model, without particularly trying to elucidate its role. Make it effortless for a developer to know what is in or out of the core."
- The Distillation Document as Process Tool
- "If the distillation document outlines the essentials of the core domain, then it serves as a practical indicator of the significance of a model change. When a model or code change affects the distillation document, it requires consultation with other team members. When the change is made, it requires immediate notification of all team members, and the dissemination of a new version of the document. Changes outside the core or to details not included in the distillation document can be integrated without consultation or notification and will be encountered by other members in the course of their work. Then the developers have the full autonomy that XP suggests."
- Cohesive Mechanisms
- "Computations sometimes reach a level of complexity that begins to bloat the design. The conceptual “what” is swamped by the mechanistic “how.” A large number of methods that provide algorithms for resolving the problem obscure the methods that express the problem."
- "Partition a conceptually cohesive mechanism into a separate lightweight framework. Particularly watch for formalisms or welldocumented categories of algorithms. Expose the capabilities of the framework with an intention-revealing interface. Now the other elements of the domain can focus on expressing the problem (“what”), delegating the intricacies of the solution (“how”) to the framework."
- Generic Subdomain Versus Cohesive Mechanism
- "Both generic subdomains and cohesive mechanisms are motivated by the same desire to unburden the core domain. The difference is the nature of the responsibility taken on. A generic subdomain is based on an expressive model that represents some aspect of how the team views the domain. In this it is no different than the core domain, just less central, less important, less specialized. A cohesive mechanism does not represent the domain; it solves some sticky computational problem posed by the expressive models."
- When a Mechanism is Part of the Core Domain
- "You almost always want to remove mechanisms from the core domain. The one exception is when a mechanism is itself proprietary and a key part of the value of the software. This is sometimes the case with highly specialized algorithms."
- Distilling to a Declarative Style
- " The value of distillation is being able to see what you are doing: cutting to the essence without being distracted by irrelevant detail. Important parts of the core domain may be able to follow a declarative style, when the supporting design provides an economical language for expressing the concepts and rules of the core while encapsulating the means of computing or enforcing them."
- Segregated Core
- "Elements in the model may partially serve the core domain and partially play supporting roles. core elements may be tightly coupled to generic ones. The conceptual cohesion of the core may not be strong or visible. All this clutter and entanglement chokes the core. Designers can’t clearly see the most important relationships, leading to a weak design."
- "Refactor the model to separate the core concepts from supporting players (including ill-defined ones) and strengthen the cohesion of the core while reducing its coupling to other code. Factor all generic or supporting elements into other objects and place them into other packages, even if this means refactoring the model in ways that separate highly coupled elements."
- The Costs of Creating a Segregated Core
- "Segregating the core will sometimes make relationships with tightly coupled non-core classes more obscure or even more complicated, but that cost is outweighed by the benefit of clarifying the core domain and making it much easier to work on."
- "The other cost, of course, is that segregating the core is a lot of work. It must be acknowledged that a decision to go to a segregated core will potentially absorb developers in changes all over the system."
- "The time to chop out a segregated core is when you have a large bounded context that is critical to the system, but where the essential part of the model is being obscured by a great deal of supporting capability."
- Evolving Team Decision
- "As with many strategic design decisions, an entire team must move to a segregated core together. This step requires a team decision process and a team disciplined and coordinated enough to carry out the decision. The challenge is to constrain everyone to use the same definition of the core while not freezing that decision. Because the core domain evolves just like every other aspect of a design, experience working with a segregated core will lead to new insights into what is essential and what is a supporting element. Those insights should feed back into a refined definition of the core domain and of the segregated core modules."
- Abstract Core
- "When there is a lot of interaction between subdomains in separate modules, either many references will have to be created between modules, which defeats much of the value of the partitioning, or the interaction will have to be made indirect, which makes the model obscure."
- "Identify the most fundamental concepts in the model and factor them into distinct classes, abstract classes, or interfaces. Design this abstract model so that it expresses most of the interaction between significant components. Place this abstract overall model in its own module, while the specialized, detailed implementation classes are left in their own modules defined by subdomain."
- Deep Models Distill
- "Although a breakthrough to a deep model provides value anywhere it happens, it is in the core domain that it can change the trajectory of an entire project."
- Choosing Refactoring Targets
- "In a pain-driven refactoring, you look to see if the root involves the core domain or the relationship of the core to a supporting element. If it does, you bite the bullet and fix that first."
- When you have the luxury of refactoring freely, you focus first on better factoring of the core domain, on improving the segregation of the core, and on purifying supporting subdomains to be generic.
