Let's talk about DDD in php

DDD is the abbreviation of "Domain Driven Design", which is often translated as domain-driven design in Chinese. Today we will introduce DDD in php. You can refer to it if necessary.

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

DDD is the abbreviation of Domain Driven Design, which is often translated as domain-driven design in Chinese. Before we understand what DDD is, let’s first discuss what it is not.

• DDD is not a software framework. However, frameworks based on DDD ideas exist, such as Axon, which is a microservice software framework implemented in Java with DDD as the guiding idea.

• DDD is not a software design pattern. It is not a design pattern like factory or singleton. However, design patterns such as Repository are proposed in DDD thinking.

• DDD is not a system architecture pattern. It is not an architectural pattern like MVC. However, DDD ideas have proposed architectural patterns such as event sourcing (Event Sourcing) and read-write isolation (Command Query Responsibility Segregation).

So what is DDD?

Software is a tool created to serve humans and improve human productivity. Each software serves a specific purpose. field of. For example, a CRM is a tool that focuses on managing customer data and helps merchants stay in touch with customers.

The essence of software is the code running in the computer. How to map the abstract code more accurately to the fields of human concern is a topic that software developers have been exploring, whether it is functional programming (FP) or object-oriented programming (OOP), both are designed to help developers develop software models that are closer to the field.

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

• Developers are keen on technology, but Lack of design and business thinking. Developers work behind closed doors without fully understanding the business needs. Even if the functions are launched, no one cares about them.

• Code input instead of business input. Technical personnel have a special liking for technology implementation, and there is a situation where there is no need to use a bull's knife to kill a chicken.

• Pay too much attention to the database. Development centered on database design rather than business often results in the software being unable to adapt to ever-changing business logic.

DDD is a design idea that takes the domain (business) as the starting point and aims to solve the complexity of software modeling. We can also understand it as a Modeling methodology.

DDD's design philosophy is divided into two parts: strategic and tactical.

We can understand strategic design as macro-level design. Its purpose includes analyzing the complexity of the business, splitting the business areas, guiding business integration methods, etc. We can understand tactical design as micro-level (code level) design, which provides us with a series of tools for implementing business logic.

Strategic Design

Universal Language (Ubiquitous Language)

Language is the basic tool for human communication. However, developers are accustomed to using technical terms, domain experts (domain experts in This generally refers to experts who are proficient in business, such as users, customers, etc.) who have no concern for technical terms, thus causing inevitable communication problems. Once communication problems occur, the software developed will be difficult to solve the real pain points of domain experts.

Universal language is the cornerstone of DDD thinking. It is a communication language that developers and domain experts jointly create. It is a common communication language that is popular in the team and can be used universally by team members. language for barrier-free communication.

This requires developers to abandon technical terms with a strong technical flavor, work with domain experts, focus on business issues like domain experts, jointly dig and polish terminology in the business, and create a common language.

General-purpose language can often be directly applied to code. It can be directly written as a class or 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(): Update the shopping cart status.

• Cart::remove(): Remove the shopping cart.

We might as well use a common language that is closer to the business:

• Cart::init(): Create a shopping cart.

• Cart::addItemToCart(): Add items.

• Cart::removeItemFromCart(): Remove the item.

• Cart::empty(): Clear the shopping cart.

When using the latter, developers do not need to explain the meaning of each class method, and domain experts can directly understand the purpose of each class method. Developers can even sit down with domain experts and work with code to hone business processes.

Bounded Context

After realizing universal language freedom, we need to use bounded context to specify the usage boundaries of each set of universal languages. Bounded context is the boundary between semantics and context. Each element within it has its own specific meaning. That is to say, every concept is unique in a bounded context, and no polysemy is allowed.

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

We use bounded context and universal language to split the business at the language level. Bounded context gives a clear concept to each element in the domain, so developers will not be tempted to flash multiple concepts that support one element in their minds, and avoid writing "big ball of mud" code. .

Subdomain

If the bounded context is to split the business at the language level, then the subdomain is to split the business value of the business. Every business has its own focus. Even if they look the same e-commerce platforms, Taobao is an open platform model, and JD.com is a value chain integration model. One obvious difference is that Taobao uses third-party logistics while JD.com builds its own logistics system. .

So as a developer, why 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 system with clear priorities to support the rapid development of a business.

Subdomain is such a tool that helps us prioritize.

There are three types of subdomains:

• Core Domain: This is the area in the system that requires the largest investment, and it represents the core competition of the entire business. force. We need to spend a lot of resources and resources to polish the core domain, which is related to the survival of an enterprise. For example, JD.com’s self-built logistics system.

• Supporting Domain (Supporting Domain): This domain is not the core business of an enterprise, but the core domain is inseparable from it. It can be implemented using outsourcing customization solutions. For example, authentication context and permission context.

• Generic Domain (Generic Domain): If there is a mature solution, the generic domain can purchase a ready-made solution. If not, you can also use outsourcing. The investment in the general domain should be is the smallest. 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 the book Implementing Domain-Driven Design.

Context Mapping

In a huge system, there must be certain dependencies between bounded contexts. How do you map concepts from one context to another? We use context mapping.

The following are several relationship types of context mapping:

• Partnership

• Shared Kernel )

• Customer-Supplier Development

• Conformist

• Anticorruption Layer

• Open Host Service

• Published Language

• SeparateWay

• Big Ball of Mud

The above are relatively abstract concepts, and sometimes there can be multiple relationships between two bounded contexts.

The above are several core concepts of DDD strategic design.

Tactical Design

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

Entity

First of all, we talk about entities.

Entities are models of independent things in the domain. Each entity has a unique identifier, such as ID, UUID, Username, etc. In most cases, an entity is mutable and its state changes over time. However, an entity does not necessarily have to be mutable.

The biggest characteristic of an entity is its individuality and uniqueness. For example, in the context of a simple shopping cart, the order is an entity, the ID is its identifier, and its status can change between placed, confirmed, and refunded.

Value Object (Value Object)

Value object is a model used to describe, quantify or measure entities in the field. Unlike entities, value objects do not have unique identifiers, and two equivalent value objects are interchangeable. Value objects have immutability. Once created, the properties of a value object are finalized and cannot be changed.

The most direct way to understand value objects is to imagine the banknotes in our real life. In daily life, A's ten yuan in RMB and B's ten yuan in RMB can be exchanged equally.

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

class Money {
  public $currency;
  public $amount;

  function __construct($currency, $amount) {
    $this->currency = $currency;
    $this->amount = $amount;
  }  
}

Using value objects for modeling can help We use code to model the domain more accurately.

Aggregation

What is aggregation? Aggregation is a more fine-grained division of business areas in context, and each aggregation ensures its own business consistency.

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

The components of aggregation are entities and value objects, and sometimes only entities. In order to protect the business consistency of the aggregate, each aggregate can only be operated through a certain entity, which is called the aggregate root.

Domain Event

Domain event is an event analyzed through a common language. Unlike common transaction events, it is closely related to business, so its naming often includes business nouns. , and should not be linked to the database. For example, when adding products to the shopping cart, the corresponding domain event should be ProductAddedToCart, not CartUpdated.

Summary

DDD also provides tactical designs such as Application Service (Application Service) and Domain Service (Domain Service). DDD also proposes event sourcing mentioned at the beginning of the article, six sides We will not introduce them one by one here.

The core of DDD is to build a model for software from a business perspective. Its purpose is to create code that is closer to the business and to clarify business processes from the code more intuitively. However, realizing DDD does not happen in a day. It requires continuous practice and continuous polishing.

Recommended learning: php video tutorial

The above is the detailed content of Let's talk about DDD in php. For more information, please follow other related articles on the PHP Chinese website!