5. Contextual Expertise

Chapter 4, “Reaching Domain-Driven Results,” established that contextual divisions with boundaries are necessary to prevent confusion in conversations with experts who use the same terminology but have different definitions of those terms. As explained in the section, “Domains and Subdomains,” there are generally multiple perspectives in a single problem space domain. It might be said that different experts view the problem space from different angles. This chapter provides concrete examples of the topics that were discussed more abstractly in Chapter 4. This will clear up any questions that might have been raised in the abstract view.

Bounded Context and Ubiquitous Language

The software development approach known as Domain-Driven Design (DDD) [Evans-DDD] addresses the contexts and communications discussed so far in the book. DDD has a name for the specialized set of conversations that take place regarding a relatively narrow sphere of knowledge, such as those depicted in Figure 4.1. In Figure 4.1, they are labeled as Scope 4 with the word Context or abbreviated as Ctx. In DDD, these conversations form what is known as a Ubiquitous Language. This language exists within a context, which is known as a Bounded Context.

Yes, Figure 4.1 is abstract because the concepts can be applied to any concrete domain. There are concrete examples of these concepts just ahead in Figure 5.1 and in the section “Business Capabilities and Contexts.”

The names Ubiquitous Language and Bounded Context might be unfamiliar and seem mysterious, but there’s no need to get hung up on them. They simply identify two of the concepts that have already been discussed extensively. They give software developers applying DDD a means to share a set of names that refer to specific design concepts that everyone involved can use:

▪ Ubiquitous Language. The team-centric common set of terms and expressions spoken in a sphere of knowledge within a specialized business expertise. Often the motivation for creating a common language for the team is the diverse backgrounds of those involved in the project, who might think of some concepts by different names. Even so, the language primarily identifies with accuracy the meanings of various terms used in the team’s specific context. That’s why outside a given context, the same terms will tend to have at least slightly, if not vastly, different meanings. The word “ubiquitous” might be a bit misleading, as it is not meant to imply that this specialized language (definitions included) is known throughout the business organization. Rather, the language is known within a single team, but is considered ubiquitous in the sense that the terms and expressions from conversations become familiar to that team and permeate the artifacts produced by the team. This is any kind of software modeling, including what’s rendered into drawings and the source code model. They all “speak” the same language.

▪ Bounded Context. The context in which a single team speaks and models software using terms, expressions, and defined business rules that reflect a specialized, acquired business knowledge—a Ubiquitous Language. The terms and expressions are not only words, but have clear definitions. The context is bounded in the sense that conversations use clearly understood meanings that occur inside the boundary are not the property of teams on the outside, and the terms and meanings used by other business efforts outside don’t penetrate the team’s established boundary. In terms of modularization, think of a Bounded Context as a coarse-grained module. How the module is to be deployed is another matter. As described in Chapter 2, “Essential Strategic Learning Tools,” modules should be chosen first and deployment options as late as possible.

Figure 4.1 shows five different Bounded Contexts, each with its own specialized Ubiquitous Language. As a rule, a single Bounded Context is owned by a single team. However, one team might own multiple Bounded Contexts. Requiring that a Bounded Context be owned by a single team ensures that conflicting goals and priorities among different teams do not cause confusing conversations and mismatched concepts in a single language.

The specialized Ubiquitous Language inside a strong boundary allows separate teams to have the same terms for concepts that have slightly or vastly different meanings, including their business rules. Consider, for example, the term product. It can have various meanings, including something that you can purchase, such as an insurance product; the result of evaluating a mathematical multiplication expression; and the software that is to be developed by using some project execution techniques. More typically, a single business will use the word product with slightly different meanings. In the insurance industry, it could well be that policy is a term used across contexts, with each context hosting a different meaning.

Trying to harmonize all the meanings of policy into a single software component is fraught with problems. DDD avoids such problems by means of a Bounded Context, which is employed to separate the various uses of the term policy. In each Bounded Context, the term policy has a well-defined meaning. The idea is to accept and embrace differences across a single business enterprise as normal rather than anomalous.

This strong boundary also allows teams to use different language terms for concepts that are similar. This might be best illustrated by thinking about multiple human languages where the same thing has completely different names. For example, the English coverage is three different words in three other languages: French, couverture; German, abdeckung; and Spanish, cobertura. Consider a Bounded Context as a national border behind which a national language is spoken. Although this analogy might seem a bit far-fetched, it is quite true that different areas of a business use completely different terms for overlapping concepts, where those terms have nuanced meanings. The idea of an insurance policy might have the following names across the business:

▪ Policy

▪ Coverage

▪ Contract

▪ Form

Possibly not readily recognized is that when such differences exist within the same organization, the different languages drive natural coarse-grained decoupling when Bounded Contexts are used to separate these clear language differences. In other words, these different terms will be used within different areas of expertise. It’s important to watch for such situations and separate them.

How is it known when the correct term is used? In fact, in the preceding examples, all four names used to refer to a policy are correct. Again, the correctness is determined by the context in which the term is used, because the four different areas of expertise are heralded by the contexts. Figure 5.1 draws attention to this point by referring to each of the five contexts from Figure 4.1 by its context name.

Each Bounded Context should be named according to its area of expertise. Within that area, the use of every term is relative to the contextual boundary:

▪ Intake Context. The Application for insurance is submitted by an Applicant.

▪ Risk Context. The Coverage contains data from the Application submitted to the Intake Context, which is used to calculate the risks associated with underwriting the policy. The dashed line points out the origin of the data used by Risk—that is, the data comes from Intake. How Risk receives the data is not necessarily indicated by the dashed line. Although the Application data originates with the Intake Context, after it is cleansed and augmented it next flows to the Underwriting Context, and then to the Risk Context.

▪ Underwriting Context. The Policy is the result of receiving the Application details, and then calculating risk of the coverage and a premium rate. The rate calculation components are not shown here, but the rate may currently be calculated by means of an integration with a Big Ball of Mud legacy system.

▪ Claims Context. The Coverage is based on data from the Policy in the Underwriting Context. The Claims area might or might not hold this data persistently. It could be obtained just in time when a claim is filed. This Coverage is different from the Coverage in the Risk Context.

▪ Renewals Context. This Policy is based on the Underwriting Policy, but is not identical to it. What is needed to renew a Policy is minimal compared to what is needed to underwrite and manage the Policy in Underwriting. The new rate might be determined by reassessing risk (not shown in Figure 5.1), which would be based on any losses filed against the Claim Coverage (or lack thereof), and in turn have an impact on the premium of a renewal.

Each of these contexts aligns one-to-one with the subdomain of the same name. That is, the business capability concept represented by the subdomain is implemented in the same-named Bounded Context.

Core Domain

A Core Domain is a subdomain within which a focused core strategic business capability is developed. It is a top-tier differentiator where the investment in radically new and innovative ideas are validated through copious communication and experimentation, and then implemented using a Bounded Context.

A Core Domain is quite literally where a business vision is focused. This is very much where the business must excel. In terms of Impact Mapping, the actors, impacts, and deliverables that deliberately drive the business toward a goal will be core. The best of business expertise and software developers compose a core team. Hence, a Core Domain warrants an investment in talent and time.

In Figure 5.1, it’s likely that Underwriting starts out as a core initiative because it is responsible for generating business. At first, human underwriters will be responsible for much of the risk evaluation and determining the premiums to match those evaluations. Yet, NuCoverage knows that it must “beat the market” through risk management using machine learning. The website that hosts the Intake and Underwriting interactions with applicants gets the early core focus. All the while, the Risk context is also being developed. At a future point when NuCoverage is confident about taking risk management out of human hands and moving it into smart actuarial mathematical models, the switch gets flipped and Intake and Underwriting become less significant.

This points to the fact that a single business might have multiple core initiatives. Within a large system development effort, there might be only initiatives, such as Underwriting and the back-office effort on Risk. Yet, the actual number of those initiatives will be consistent with the level of innovation required to reach a business goal. It’s not as if stating some arbitrary limitation on the practical number of core initiatives is unhelpful. As always, it depends. A key constraint is the talent already onboard and the talent that can be recruited and put into core initiatives.

Our use of the term talent here strongly implies that communication with a scientific, experimental mindset is a must. The intelligence, creativity, and drive of these people should be scary, and they will be available only in exchange for compensation equal to their abilities. Innovation has a price tag, kind of like the car driven by a Fortune 500 CEO. All the same, talent is no excuse for arrogance and drama. The best people work in teams and know they can’t do it all alone, because they understand their own limitations.

Early on, a startup business might struggle to focus on one or a few things, but it must learn where its business will earn revenues and how it will succeed. Recalling the germination of an idea and how it was pitched for venture funding can help the organization retain or regain focus. Adopting an Objectives and Key Results (OKRs) process has taken some small startups to valuations of hundreds of billions of dollars [Measure]. If it’s not careful, though, a startup might be destined toward entropy—but at least it has the advantage that it doesn’t begin in that position. This enables fast innovation.

For a large enterprise, it might be less of a struggle to know what the core focus should be, but the challenges will very likely lie in where and how that focus should be realized. An established enterprise likely starts from a state of entropy and must struggle to deal with not breaking its existing digital assets. The discussion in the section “Context Mapping,” in Chapter 6, “Mapping, Failing, and Succeeding—Choose Two,” can help the business manage this condition.

Further, a core modeling effort will very likely not remain core over a very long time frame. New investments will continue with necessary new innovations. What is core today might be a supporting part of a newer initiative at some point in the future.

Supporting Subdomains, Generic Subdomains, and Technical Mechanisms

A business can’t afford to invest everywhere to the same degree it does in a Core Domain, nor does it need to. Although absolutely necessary to have, many parts of a large system are neither interesting nor worthy of deep investment. These less significant subdomains of a system are there to support the overall function of the core parts.

Such lesser domains tend to fall into two primary areas: supporting and generic subdomains. We can also add to these another typical sideshow that has little to do with the actual business: technical mechanisms.

Supporting Subdomains

A supporting subdomain is one that is necessary to provide support to the functionality of a Core Domain, but does not deserve the steep investment that should go into the core. A supporting subdomain likely does not consist of a commercial software product offering that can be licensed, or for which a subscription is available. If such a supporting subdomain does exist commercially, it is very likely that it is highly configurable and customizable.

Because a supporting subdomain might not be available for purchase, it will almost certainly have to be custom developed. Yet, because it is not core, a team should not run up exorbitant expenses in this supporting area of the system. For one thing, the talent selected to work on this subdomain should not be top shelf. Although the subdomain talent will undoubtedly need to communicate with the business experts, the necessary discussions might be driven more by a core team because the core team knows what they need to support their efforts.

Another kind of a supporting subdomain is a legacy subsystem with a business capability that can be reused. There will almost certainly be a need to create an interface to the legacy operations that provides a better integration experience than what might (or might not) already exist. Again, the section “Context Mapping” in Chapter 6 addresses the means to deal with this issue in several ways.

As an example, two legacy supporting subdomains for NuCoverage are risk management and premium rate calculations. Integration interfaces must be developed for both because their use is currently internal to the legacy system. In the long run, it will be best to break these assets out of the legacy system and move them into contexts of their own to enable frequent changes to them. This will happen sooner with risk management because it will transition to a Core Domain.

Generic Subdomains

A generic subdomain is complex and requires a great deal of domain expertise to develop, but one that is available through multiple commercial closed source or open source products. Think of two or more products that are compared side-by-side using feature lists with check boxes. For both products, nearly every one of the dozens of check boxes are checked. Which one should be selected? Perhaps the decision should be made based on perceived reputational advantage, greater total number of customers for one of the products, length of time on the market, or other semi-tangible or intangible aspects.

For NuCoverage, examples of generic subdomains might include industry-standard risk models, policy document formatting and generation, photo image scanning for applications and claims, bulk sales and marketing email providers, customer relationship management, enterprise resource planning, identity and access management, and the like.

Technical Mechanisms

Unfortunately, some of the lowest-level areas of software development tend to attract the attention of developers because they are frequently more technical in nature. Management must be careful not to allow the best talent to become pigeonholed into these areas that might be entertaining in terms of leading-edge technology, but do not yield much bang for the buck when it comes to the business’s bottom line. The actual business aspects associated with these tools—if there are any beyond data persistence and movement—are less demanding of thoughtful modeling. The innovation is already present in the mechanism.

In terms of the technology attractions, expect to see some of the latest in cloud infrastructure and application programming interfaces (APIs), deployment containers, databases, web user interface frameworks, network communications, messaging, and anything that promises the potential for large scale and high throughput. Although some doses of these mechanisms that make data move and the enterprise tick are definitely called for, be forewarned that these programmer magnets are not worthy of the undivided attention that they commonly receive. Make business innovation challenges greater than the appeal of leading-edge technology.

Business Capabilities and Contexts

Chapter 2 discussed the importance of organizing teams around business capabilities and capturing critical design communication within the modules separating business capabilities. The Bounded Context, for example, is a top-level, coarse-grained module where a business capability is housed.

Over the long term, the Bounded Context might not remain what it was originally envisioned to be. Boundaries might change. For example, when breaking up a Big Ball of Mud, the teams involved might find a business capability known as Policyholder Accounts. This is where all policyholders of any kind of policies are managed, and it makes sense that this capability includes some knowledge of the kinds of policies they each hold.

One of the concepts held inside this module is digital policy documents acknowledging rewards given to exemplary policyholders. Because car insurance was the first business in which NuCoverage engaged, the one supported reward is the Safe Driver Reward. It seemed logical to maintain the Safe Driver Reward with mainstream policy information. Yet, over time NuCoverage began to introduce new insurance products, including new kinds of rewards. For example, health insurance products are associated with Good Health Rewards, and similar rewards are offered with life insurance. These rewards are meant not only to improve the driving and health of individual policyholders, but also to lower the risk of auto accidents, healthcare costs, and premature death as financial impacts on NuCoverage.

As these rewards began to grow in number, clearly a new business capability and a new area of expertise began to form. Now it makes sense to break out the rewards from Policyholder Accounts into their own specific coarse-grained module. The Reward Programs Context is the chosen name of the new Bounded Context. Rewards-related conversations and learning opportunities are addressed inside this context. At some point in the future, it might be best to break specific rewards into their own Bounded Contexts.

A well-designed microservice should encompass the business capability, which means that a first good step is to consider a microservice as a Bounded Context. This determines what you put inside the service—namely, a modeled business capability that is reflected in a Ubiquitous Language. The service should be autonomous, supporting a model as data and operations with business rules. This approach should be used as extensively as possible over a whole system solution, leaving no questions about where the business capabilities are within the whole. Of course, this doesn’t mean that every Big Ball of Mud can be replaced in the short term, but using Context Mapping (described in more detail in Chapter 6) is a way to fabricate an explicit surfacing of a subdomain.

A Bounded Context containing a single business capability transcends technology boundaries. If the architectural layers include a web user interface, then some form of client code running as JavaScript will be involved in expressing the Ubiquitous Language. Further, the primary services will be implemented using a foundational runtime platform, such as Java or .NET. Unsurprisingly, the model-based business capabilities might use a polyglot of programming languages as well as runtime platforms to capitalize on the specific technical advantages afforded by these supports.

The enterprise business divisions, departments, or lines are not always a good indication of where the business capabilities are found. Computing has gradually had an increasing impact on business operations, where workflows were previously driven by file cabinets and memos moving from desk to desk. Now there’s much greater use of electronic folders, files, email, and workflow routing. Yet, none of the previous or current business operations and data access practices defined the capabilities of a business. Thus, business capabilities should not be confused with business processes (operational details ending in “ing,” such as pricing), which might encompass multiple business capabilities to fully address a business operation.

To fully understand how to implement a business capability using #agile requires an examination of the user working in their natural environment. Otherwise, the team risks missing out on collecting important steps and gestures within the daily workflow of users. Such an investigation will almost certainly uncover pain points and workarounds that should be addressed by improving the system. For example, suppose you observe a user who has one or many sticky notes on their display, or a spreadsheet containing usage instructions, to help them remember how to navigate to and use important software features in the application. That points to a problem that must be recognized and remedied. This is part of fully developing a sphere of knowledge within each business capability.

Not Too Big, Not Too Small

The section “Are Microservices Good?” in Chapter 1, “Business Goals and Digital Transformation,” established that Microservices are not about size but rather about the purpose. The word “micro” is misleading in the way that it implies some kind of size constraints. Yet, it should not convey those connotations. Refer back to the discussion in Chapter 1 for more details.

As far as Microservices or modularized Monoliths are concerned, the same kinds of modularizations and design practices apply because these are all focused on Bounded Contexts. Thus, you might instead ask: How large is a Bounded Context? Although this is sort of the wrong question, the answer is another question: How large is the Ubiquitous Language within the context? In other words, size cannot be accurately measured as a standard goal because it is highly contextual.

A Bounded Context is the encapsulation of a business capability, and each business capability must have a complete implementation. There shouldn’t be any part of a given business capability left over or implemented outside of its Bounded Context. The only design driving force for Bounded Contexts should be the scope of the business capability and its Ubiquitous Language, and not the size.

With these considerations in mind, a Bounded Context is typically not tiny-tiny, as in 100 lines of code. And although it’s unlikely that a full business capability could be implemented in 100 lines of any programming language code, it could be, if that’s what it takes to implement it. Further, a single Bounded Context on its own would be very unlikely to be a Monolith.

It’s fair to conclude that a Bounded Context will tend to be smallish. When that’s true, thinking of a Bounded Context as a Microservice is a good enough place to start. If other drivers cause the corresponding business capability to change in some way, such as being divided into multiple business capabilities, then transform it into multiple Bounded Contexts according to the drivers. A reason for this was demonstrated previously with the growing number of policyholder rewards. Conversely, if there is a rate of change, or technical scale and/or performance drivers, then respond to those drivers. In these three cases, the deployments might change, but the logical Bounded Context remains intact. Assuming that these drivers exist from the start, but with no empirical evidence, will harm the system under design. Making any necessary changes at the last responsible moment is #agile thinking, and a better choice.

Summary

This chapter introduced Domain-Driven Design with a focus on two strategic modeling artifacts, the Ubiquitous Language and the Bounded Context. The specialized Bounded Context known as a Core Domain is where a strategic business capability is developed. The chapter also offered views on different kinds of business subdomains and how they connect to the business capabilities and their Bounded Contexts.

The most salient points are:

▪ A Ubiquitous Language represents the conversations that take place in a relatively narrow sphere of knowledge that is contextualized by a Bounded Context.

▪ Each business concept, the meanings of various terms, and the constraining business rules used in the specific language of a context are both accurate and unambiguous.

▪ Bounded Context delimits the applicability of its Ubiquitous Language.

▪ Each Bounded Context should be owned by a single team, but a team can own several Bounded Contexts.

▪ The Core Domain is where the business vision is focused and an investment in talent and time is made.

▪ The size of the Bounded Context should be delimited by the scope of the business capability and its Ubiquitous Language.

Chapter 6 introduces tools to help map team relationships, collaboration, and integrations between multiple contexts of expertise. The mapping types address a broad range of inter-team situations, communication channels, and ways to exchange information and request behavior from integration sources.

References

[Evans-DDD] Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston: Addison-Wesley, 2004.

[Measure] John Doerr. Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs. New York: Portfolio, 2018.