What is Domain-Driven Design笔记：C1.Analyzing Business Domains

拼搏现实的明天。 2022-10-16 09:41 55阅读 0赞

In this chapter, you will learn about domain-driven design’s concepts for analyzing a company’s business: the business domain; core, supporting, and generic subdomains; and domain experts.

在这一节，你将学习通过DDD从公司商业角度进行分析的概念: 商业域、核心域、支撑域、通用域 以及领域专家

#### What Is a Business Domain? ####

A business domain defines the company’s overall area of activity. Generally speaking, it’s the service the company provides to its clients. For example:

FedEx—courier delivery

Starbucks—coffee

Walmart—retail

A company can operate in multiple business domains. For example, Amazon provides both retail and cloud computing services. Uber is a ridesharing company that also provides food delivery and bicycle-sharing services.

It’s important to note that companies change their business domains often. A canonical example here is Nokia, which over its lifetime has operated in fields as diverse as wood processing, rubber manufacturing, telecommunications, and mobile devices.

### What Is a Subdomain? ###

To achieve its business domain’s goals and targets, a company has to operate in multiple subdomains. A subdomain is a fine-grained area of business activity. All the subdomains together add up to the company’s business domain—the service it provides to its customers. Implementing a single subdomain is not enough for a company to succeed.

Often subdomains correlate to the company’s departments or other organizational units. For example, an online retail shop might include subdomains such as catalog management, advertising, accounting, support, customer relations, supplier relations, and others.

From a technical perspective, subdomains resemble sets of interrelated use cases. Consider the use case diagram in Figure 1-1 for a credit card payment gateway.  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x0aGlyZG9uZWw_size_16_color_FFFFFF_t_70]

Use case diagram of a credit card payment subdomain  
Figure 1-1. Use case diagram of a credit card payment subdomain  
This diagram represents a coherent set of use cases, operating on the same set of actors and business entities. Hence, all these use cases form the “credit card payments” subdomain.

### Types of Subdomains ###

Domain-driven design distinguishes three types of subdomains: core, generic, and supporting. Let’s see how they differ from a company strategy point of view.

**CORE SUBDOMAINS**

A core subdomain is what a company does differently from its competitors. This may involve inventing new products or services, or optimizing existing processes and thereby reducing costs.

Let’s take Uber as an example. Initially, the company provided a novel form of transportation—ridesharing. As its competitors caught up, Uber found ways to optimize and evolve its core business: for example, reducing costs by matching riders heading in the same direction.

**Complexity and rate of change**  
A simple-to-implement core subdomain can only provide a short-lived competitive advantage. Therefore, core subdomains are naturally complex. There should be high entry barriers for a company’s core business; it should be hard for competitors to copy or imitate the company’s solution.

Core subdomains also tend to change often. It should be part of a company’s business strategy to innovate and evolve its core subdomains continuously. The changes to core subdomains will come in the form of adding new features or optimizing the behavior and ROI of existing ones. Either way, the constant evolution of its core business is essential for a company to stay ahead of its competitors.

**Implementation concerns**  
Core subdomains have to be implemented in-house. They cannot be bought or adopted; that would undermine the notion of competitive advantage, as the company’s competitors would be able to do the same.

It would also be unwise to outsource the implementation of a core subdomain. It is a strategic investment. Cutting corners on a core subdomain is not only risky in the short term, but can have fatal consequences in the long run: for example, unmaintainable codebases that cannot support the company’s goals and objectives. Therefore, the organization’s most skilled talent should be assigned to working on its core subdomains.

From a technical perspective, maintainability and evolution of the business logic are of high importance. Hence, core subdomains require the implementation of the most advanced engineering techniques.

**Nature of core subdomains**  
It’s important to note that core subdomains are not necessarily technical. Not all business problems are solved through algorithms or other technical solutions. A company’s competitive advantage can come from different strategies.

Consider, for example, a jewelry maker selling its products online. The online shop is important, but it’s not a core subdomain. The jewelry design is. The company can use an existing off-the-shelf online shop engine, but it cannot outsource the design of its jewelry. The design is the reason customers are buying the jewelry maker’s products.

### GENERIC SUBDOMAINS ###

Like the core subdomains, generic subdomains are generally complex and hard to implement. However, generic subdomains do not provide any competitive edge for the company. There is no need for innovation or optimization here: battle-tested implementations are widely available, and all companies use them. In other words, generic subdomains are business activities that all companies are performing in the same way.

For example, most systems need to authenticate and authorize their users. Instead of inventing a proprietary authentication mechanism, it makes more sense to use an existing solution. Such a solution is likely to be more reliable and secure since it has already been tested by many other companies having the same needs.

**Implementation concerns**  
Generic subdomains are hard but already solved problems. It’s more cost-effective to buy an off-the-shelf product or adopt an open-source solution than to invest time and effort into implementing a generic subdomain in-house.

### SUPPORTING SUBDOMAINS ###

As the name suggests, supporting subdomains support the company’s business. However, contrary to the core subdomains, supporting subdomains do not provide any competitive advantage for the company. They simply support the company’s core business.

For example, consider an online advertising company. Its core subdomains include matching ads to visitors, optimizing ads’ effectiveness, and minimizing ad spaces’ costs. However, to achieve success in these areas, the company needs to catalog its creative materials. The way the company manages its creatives does not impact its profits. There is nothing to invent or optimize in that area. On the other hand, the creative catalog is essential for implementing its advertising management and serving systems. That makes the content cataloging solution one of the company’s supporting subdomains.

**Complexity and rate of change**  
The most striking difference between core and supporting subdomains is the complexity of the business logic. Supporting subdomains are simple. Their business logic resembles data entry screens and ETL (extract, transform, load) operations; i.e., the so-called CRUD (create, read, update, and delete) interfaces.

Also, contrary to the core subdomains, supporting subdomains do not change often. They do not provide any competitive advantage for the company, and therefore there is no business value in evolving them over time.

**Implementation concerns**  
Lack of competitive advantage makes it reasonable to avoid implementing supporting subdomains in-house. However, unlike with generic subdomains, no ready-made solutions are available. Hence, a company has no choice but to implement supporting subdomains itself. That said, the simplicity of the business logic and infrequency of changes make it easy to cut corners.

Supporting subdomains do not require elaborate design patterns or other advanced engineering techniques. A rapid application development framework will suffice to implement the business logic without introducing accidental complexities.

From a staffing perspective, supporting subdomains do not require highly skilled engineers. Save them for the core subdomains. Also, the simplicity of the business logic makes supporting subdomains a perfect candidate for outsourcing.

## Who Are Domain Experts? ##

Let’s take a look at another DDD term related to business domains that we are going to use often in the next chapters: domain experts. Domain experts are subject matter experts that know all the intricacies of the business that we are going to model and implement in code. In other words, domain experts are knowledge authorities in the software’s business domain.

The domain experts are neither the analysts that gather requirements nor the engineers designing the system. Domain experts represent the business. They are the people that identified the business problem in the first place, and all business knowledge originates from the domain experts. Systems analysts and engineers are just transforming their mental models of the business domain into software requirements and source code.

As a rule of thumb, domain experts are either the people coming up with requirements or the software’s end users. The software is supposed to solve their problems.

The domain experts’ expertise can have different scopes. Some subject matter experts will have a detailed understanding of how the whole business domain operates, while others will specialize in particular subdomains. For example, in an online advertising agency the domain experts would be campaign managers, media buyers, analysts, and other business stakeholders.

## Conclusion ##

We’ve now covered domain-driven design’s tools for making sense of a company’s business activity. As you’ve seen, it all starts with the business domain—the area the business operates in and the service it provides to its clients.

You also learned about the different building blocks required to achieve success in a business domain, including the following:

**Core subdomains**  
The interesting problems. Activities that the company is performing differently from its competitors, and from which it gains its competitive advantage.

**Generic subdomains**  
The solved problems. Things that all companies are doing in the same way. There is no room or need for innovation here; rather than creating in-house implementations, it’s more cost-effective to use existing solutions.

**Supporting subdomains**  
The boring problems. Activities that the company likely has to implement in house, but that do not provide any competitive advantage.

Finally, you learned that domain experts are the business’s subject matter experts. They have in-depth knowledge of the company’s business domain or one or more of its subdomains and are critical to a project’s success.

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x0aGlyZG9uZWw_size_16_color_FFFFFF_t_70]: /images/20221014/b0595cbd05114ad18b507eac9640850c.png