This article is reprinted from how to decouple: codedecoupled.com/intro-ddd.h…

What DDD is (first of all what it is not)

DDD is the abbreviation of Domain Driven Design, which is often translated as Domain Driven Design in Chinese. Before we look at what DDD is, let’s discuss what it is not.

  • DDD is not a software framework. But ddD-based frameworks exist, such as Axon, a ddD-based microservices software framework implemented in Java.
  • DDD is not a software design pattern. It’s not a design pattern like factory singletons. However, DDD ideas propose design patterns such as Repository.
  • DDD is not a system architecture pattern. It’s not an architectural pattern like MVC. However, SOME architectural patterns such as Event Souring and Command Query Responsibility Segregation were put forward in DDD.

So what exactly is DDD

Software is a tool that serves human beings and improves human productivity. Each software serves a specific field. For example, CRM is a tool to manage customer data and help merchants keep in touch with customers.

And the essence of the software is running in the computer code, how to abstract the code mapped to more accurately in the areas of human concern, which is a software developers have been exploring topics, whether it’s functional programming (FP) and object oriented programming (OOP), is to help developers to develop closer to the model in the field of software.

In traditional software development methods, we often encounter a series of technical and non-technical problems that affect software quality:

  • Developers love technology, but lack design and business thinking. Developers don’t fully understand the business requirements, they go behind closed doors, and even when features come online, nobody cares.
  • Code input instead of business input. Technical personnel have a special liking to the realization of technology, the occurrence of how to kill a chicken with a sword.
  • Too much emphasis on databases. Focusing on database design rather than business development often results in software failing to adapt to the ever-changing business logic.

DDD is a design idea, a domain-oriented (business) design idea aimed at addressing software modeling complexity, and we can also think of it as a modeling methodology.

The design idea of DDD is divided into strategic and tactical parts.

We can understand the strategic design as the design at the macro level. Its purpose includes analyzing the complexity of the business, dividing the business domain, guiding the way of business integration and so on. We can think of tactical design as design at the micro level (code level), which provides us with a set of tools for implementing business logic.

Strategic design

Ubiquitous Language

Language is the fundamental tool of human communication, but developers accustomed to use technical terms, the domain experts (here refers to master the business experts, such as a user, customer, etc.) concerned about technical terms, then the inevitable communication problems caused by once communication problems, developed by the software, it’s very difficult to solve real pain points of experts in the field.

A common language is the cornerstone of DDD thinking. It is a common language for developers and domain experts to create a common language that is popular in a team and can be used by team members to communicate with each other without barriers.

This requires developers to abandon technical jargon and work with domain experts to focus on business issues as domain experts do, mining and honing business jargon to create a common language.

A common language can often be applied directly to code. It can be written directly as a class or as a method of a class.

For example, when developing a shopping cart, instead of using technical terms:

  • Cart::create(): Create a shopping cart.
  • Cart::updateStatus(): Updates the shopping cart status.
  • Cart::remove(): Remove the shopping cart.

We might as well use a more business-friendly generic language:

  • Cart::init(): Create a shopping cart.
  • Cart::addItemToCart(): Add a commodity.
  • Cart::removeItemFromCart(): Remove an item.
  • Cart::empty(): Empty the shopping cart.

With the latter, the developer does not have to explain the meaning of each class method, and the domain expert can directly understand the purpose of each class method. Developers can even sit down with domain experts to hone business processes using code.

Bounded Context

After the implementation of universal language freedom, we need to use a bounding context to define the use boundaries of each set of universal languages. A bounding context is the boundary between meaning and context, in which every element has its own specific meaning, that is to say, every concept is unique in a bounding context, and polysemy cannot occur.

We can use a simple example to explain the bounded context. For example, in the bounded context of a shopping cart, we can use the word User to represent the customer who buys the item. In a registration system, we can use the word User to refer to an account with a User name and password. Although the words are the same, they have different meanings in different bounded contexts.

We use bounded contexts and common language to split the business at the language level. Bounded contexts give a clear idea of each element in the domain, and developers are not tempted to flash multiple concepts supporting an element in their minds, avoiding writing “big ball of mud” code.

Subdomains (Subdomain)

If a bounded context is a linguistic separation of business, then a subdomain is a commercial separation of business value. Every business has its own focus. Even for e-commerce platforms that look the same, Taobao is an open platform model while JINGdong is an integrated value chain model. An obvious difference is that Taobao uses third-party logistics while Jingdong builds its own logistics system.

So why, as a developer, should you care about a business model that seems to have nothing to do with you? On the contrary, only when we understand the structure of a business can we develop a prioritized system to support the rapid growth of a business.

Subdomains are one such tool to help us prioritize.

There are three types of subdomains:

  • Core Domain: This is the area of the system that requires the most investment and represents the Core competence of the entire business. We need to spend a lot of resources and resources to polish the core domain, which is the survival of an enterprise. Take JD.com’s own logistics system.
  • Supporting Domain: This Domain is not the core business of an enterprise, but it is inseparable from the core Domain, which can be achieved by outsourcing customized solutions. Such as authentication context, permission context.
  • Generic domains: Generic domains can be purchased off-the-shelf if a proven solution exists, or outsourced if not, with minimal investment. For example, for Taobao, logistics is its general domain.

There are different opinions on the relationship between bounded context and subdomain. Some experts advocate 1:1, while others advocate 1:N. Personally, I advocate 1:1, because I am deeply influenced by the author of a book on implementation domain-driven design.

Context Mapping

In a large system, there must be some dependence between bounded contexts. How do you map concepts in one context to another? We use context mapping.

Here are several relational types of context mapping:

  • Partnership
  • Shared Kernel
  • Customer-Supplier Development
  • Conformist (Conformist)
  • Anticorruption Layer
  • Open Host Service
  • Published Language
  • Find another way.
  • Big Ball of Mud

These are abstract concepts, but sometimes there can be multiple relationships between two bounded contexts.

These are the core concepts of DDD strategy design.

Tactical design

To model concepts in bounded contexts, we will use the tactical design provided by DDD.

Entity (Entity)

The first thing we talked about was entities.

Entities are models of individual things in a domain, each of which has a unique identifier such as ID, UUID, Username, and so on. In most cases, an entity is mutable and its state changes over time, but an entity does not have to be mutable.

The greatest characteristic of an entity is its individuality, its uniqueness. In the context of a simple shopping cart, for example, an Order is an entity, its ID is its identifier, and its state can vary between posted, confirmed, and refunded.

Value Object

A value object is a model used in a domain to describe, quantify, or measure entities. Unlike entities, value objects do not have unique identifiers, and two equivalent value objects can be replaced. Value objects have Immutability. Once created, the properties of a value object are fixed and cannot be changed.

The most straightforward way to think about value objects is to think about money in our real life. In our daily life, 10 yuan of A and 10 yuan of B can be exchanged equally.

In the shopping cart context above, Money is a value object consisting of currency and amount:

class Money { public $currency; public $amount; function __construct($currency, $amount) { $this->currency = $currency; $this->amount = $amount; }}Copy the code

Modeling with value objects helps us model the domain more precisely with our code.

Polymerization (Aggregate)

What is aggregation? Aggregation is a more detailed division of business domains in context, with each aggregation guaranteeing its own business consistency.

So what is business immutability? Business immutability represents a business rule that cannot be violated in the business domain and whose consistency must be guaranteed. For example, when an order is refunded, the refund amount cannot exceed the amount paid.

The components of aggregation are entities and value objects, sometimes just entities. To protect the business consistency of the aggregation, each aggregation can be operated on through only one entity, called the aggregation root.

Domain Events

Domain events are events that are analyzed in a common language. Unlike common transaction events, domain events are business related, so they are often named with business nouns and should not be linked to a database. For example, adding items to a shopping cart should correspond to a domain event called ProductAddedToCart, not CartUpdated.

conclusion

DDD also provides tactical design such as Application Service, Domain Service, etc. DDD also proposes the event source, hexagon and other architectural patterns mentioned in the beginning of this article, which we will not introduce in detail here.

The core of DDD is to model software from a business perspective. The purpose of DDD is to create code that is closer to the business and to make business processes more intuitive from the code. However, implementing DDD is not a one-day process, it requires continuous practice and continuous polishing.

If you are also interested in TDD, DDD, and clean code, you are welcome to explore the ways of software development on the public account “Why Decouple”.

This article is reprinted from how to decouple: codedecoupled.com/intro-ddd.h…