Author: Xiao Fu Ge blog: bugstack.cn original text: mp.weixin.qq.com/s/ezd-6xkRi…

Precipitation, share, grow, let yourself and others can gain something! 😄

One, foreword

Leader: Why use DDD?

I also thought hard about how to tell my leaders to upgrade from MVC to DDD, because DDD code structure is clearer, domain-driven development is more advanced than test-driven development, and the developers want to use the new framework.

But why is it that, instead of being criticized, you’re overdesigning? Because we missed the point, you MVC upgrade DDD; Did it bring anything to the business, improved delivery efficiency, reduced r&d costs? None? Not only no, you also said that more design and development time would be needed in the early stage for later iteration maintenance. Zha? Do you want to send me away with a Q? I just came to our department and THE KPI was hanging there, which made my hair turn white! Don’t mess around. Play it safe!

So we don’t do it? Oh, no! No change of leadership! Before you do that, consider that DDD is not Silver Bullet. You have a passion for DDD, but you also need to know what the design principles of DDD are, what scenarios are better suited to DDD, and how it compares to MVC.

Second, development costs

What are the costs of developing code using DDD mode? Is it because using DDD four tiers is more time-consuming than MVC three tiers? In fact, it is not, because compared with the three-tier structure, the four-tier structure can better distinguish the responsibility of the code, and the development will be more smooth after being familiar with the functional responsibility of the module.

So what are the costs of DDD driven design development here? This cost is the cost of storm model design for a complex system with sufficient experience in separating responsibility boundaries, dividing functional areas, clarifying choreography logic, and controlling unknown process extensions before they are developed.

However, the commonly used MVC structure basically does not appear such a problem, because in the actual code, DAO, PO, VO and so on are all shared. When developing the code, we can write the code oriented to the process like a pile of mud balls, and directly connect the PRD function nodes of the product without thinking too much about decoupling and cohesion.

Isn’t it possible to design patterns? It depends on what dimension you’re thinking about. Design patterns here are tactical issues, DDD and MVC are strategic issues, sort of saying “Wrong direction, wasted effort.”

Now let’s look at the development cost curve:

  • When using DDD, there is a higher upfront cost of time to model the design domain, as compared to the other two hierarchies.
  • However, as the logic of the business grows in complexity over time, the DDD system architecture develops more stable code, which means DDD is easier to scale up and maintain.
  • So the change of the framework structure is not where the development cost is going to end up. If you don’t do domain modeling and don’t do a lot of design thinking, then even the four-tier DDD architecture will allow you to write MVC effects. For those architects or developers who are experienced in business scenarios, they have already clearly defined the responsibility boundaries of each business function, and what core domain services need to be completed to achieve a system requirement. In this case, DDD will not bring much development cost, but more easily.That’s why domain experts are needed, because experts have accumulated a lot of experience in strategic design, right
  • In addition use of DDD domain driven design mode of development, in addition to solve the iteration cost of demand, more is to face the company strategic adjustment, system transition, the replacement of personnel and new, are under the original project architecture continues to iterative development, will overturn to do otherwise, as facing the replacement cost will be more big, At the same time, it also develops a project code that is bound to personnel and not easy to transfer and maintain.

Third, architecture comparison

On your way to understanding and mastering DDD domain driven design, you are bound to encounter two abstract obstacles — the “anaemic model” and the “congested model” :

  • Anaemic model: Transaction script pattern, originally originated in EJB2, has entered its heyday in Spring.
  • Congestion model: Domain model patterns, 2003, up toImplementing Domain-Driven DesignThe advent of DDD opened the door.However, DDD fever did not begin until the rise of micro services and low code in China

1. MVC

The MVC hierarchy will: “State” (data, member objects), “behavior” (logic, process), separated into different objects, only the state of the Object (VO -> Value Object) is called anaemic model, only the behavior of the Object, Is a common Logic/Service/Manager layer in the framework layer (corresponding to the Stateless Session Bean in EJB2)

  • Use DAO, PO in the application layer Service infrastructure packing way of the development of the business logic, at first glance thought the application layer is in the implementation of domain modeling, “domain layer” link, has a wealth of object and the real domain model is also very similar, but when we code as in the gradual implementation of business logic function will gradually found, we write a lotget/setObjects, while they are used repeatedly, are not aggregated with any domain, that is, do not have any behavior, just a bunch of anaemic model objects.
  • The design of this antipattern is completely differentobject-orientedIn contrast to object-oriented design, which prefers behavior and data binding, anemic models are more process-oriented.
  • Under the MVC hierarchy, all the behavior is written into the Service object, and you end up with a set of transaction process scripts that perfectly sidestep the benefits of domain model design (clear responsibility boundaries, converged functional services, clear object-oriented).

2. DDD

The layered structure of DDD is also the essence of object-oriented programming: “an object owns behavior and data,” including objects, aggregate objects, repositories, and Service implementations at the domain level.

  • The hierarchical structure of DDD pays more attention to the implementation of the Domain layer. The thin application layer defines the interface and choreographs the interface, and the Domain layer does the concrete implementation.
  • All business logic is broken down into functional areas along their responsibility boundaries, and each functional area is a concrete implementation of the structure of the congestion model.
  • After such code is finally realized, no matter in the process of iteration, maintenance or staff replacement, the corresponding code implementation can be found according to the domain design document for development.

4. Design principles

First, DDD design is divided into strategic and tactical.

  • Strategic design: from the business perspective, establish business domain model, divide responsibility boundaries, establish the boundary context of common language. The domain model structure constructed by the top-level strategic design is the focus of the whole service late-stage choreography. It determines the responsibility boundary, aggregation and object of functions, which absolutely determines the development and delivery quality of late-stage service tactical implementation.Pay attention to strategy, can land good tactics!
  • Tactical design: from a technical perspective, focus on the technical implementation of domain models, complete functional development and delivery. The focus of domain design includes entities, aggregate objects, value objects, domain services, warehousing, and a very important oneDesign patterns. Any implementation of a more complex domain model needs to consider the use of design patterns, otherwise even if the strategy is good, the tactics will go back to MVC.

In DDD domain driven design landing process, must rely on the design thought of domain driven design, field model is established by storm events, reasonable division of domain logic and physical boundaries, establish a domain object and the matrix and the architecture diagram of the service definition in DDD code structure model of layered architecture thought, to ensure the consistency of the business model and the code model. Through the above design ideas, methods and processes, guide the team to complete the design and development of microservices according to DDD design ideas.

  1. Refuse mud ball small monomer, refuse pollution function and service, refuse to add function schedule for one month
  2. Architecture of highly available easy to conform to the High-speed iteration of the Internet application services
  3. Materialized, assembled and choreographed services improve human efficiency
  4. Domain driven design, not data driven design, not interface driven design
  5. A clear hierarchy of functions, rather than a laundry list of everything

DDD’s domain-model design, within context boundaries, can be split into separate microservices. However, we should not only look at the problem from the business perspective, but also consider non-business technical factors, including high performance, security, team, technology heterogeneity, etc. These non-business technical factors will also determine the specific implementation of the domain model.

Take an example

You say my MVC is not good, you say my MVC anaemic model, PO class continues to expand, but let me use DDD are all theory, programmers prefer to see is already implemented code, tell me how to do.

Why is it so hard to land? Because the transition from MVC to DDD description comparison only accumulates the lessons of MVC failure, but does not have DDD success experience, so most of the time, in addition to theoretical support, need a case in front of the implementation of DDD.

1. Engineering structure

So in order to let more code farmers see a way to go in DDD, specially toss over a DDD distributed lottery system, to tell you how to use DDD development business needs;

The overall system architecture design includes six projects:

  1. Lottery: a distributed deployed Lottery service system that provides Lottery business domain functions and RPC services in a distributed deployed manner.
  2. Lottery-api: gateway API service that provides; H5 page lucky draw, public number development reply message lucky draw.
  3. Lottery-front: C-side user system, Vue H5 Lucky – Canvas large rotary table Lottery interface, explains vUE project creation, module introduction, development interface, cross-domain access and function implementation
  4. Lottery-erp: B-side operation system, which can meet the needs of operators for activities query, configuration, modification, review and other operations.
  5. Db-router: sub-database sub-table routing component, the development of a HashMap based on the core design principle, the use of hash hash + disturbance function, the data hash to multiple library table components, and verify the use of.
  6. Lottery-test: a Test validation system used to Test validation of RPC services and system function calls.

2. Process disassembly

When we get the RPD of the product, we are not directly involved in development, but need to disassemble a domain service of object-oriented design from the process, for example;

  • Disassembling functional processes and refining domain services teaches you step by step how to disassemble a business functional process into domain modules under each responsibility boundary, and provide the whole service link by connecting developed domain services in series at the application layer.
  • Through such design and implementation ideas, as well as in the process of the function in accordance with the object-oriented design mode of design, so that every step of the code becomes clear and easy to understand, so that the code is easier to maintain and expand.
  • So, what you learn in this process is not only code development, but also more practical ideas. It can also lay a good foundation for you to develop such a project in the future or in the interview process, some of the actual complex scene questions design ideas.

3. Practice together

If you are interested in DDD practice learning, you can also join the DDD distributed lottery system to absorb a solid experience. PS: Spend some money on yourself, make a worthwhile investment, and buy less skin

Learning links: bugstack.cn/md/project/…

  • Developers with Java programming background want to improve their technical skills
  • Hope to improve coding thinking and eliminate the bad taste in the code
  • Willing to become an architect, but still at a bottleneck
  • Want to join the big factory to do code farming, but the total feeling can not find the way

Six, summarized

  • DDD is not Silver Bullet, and you don’t expect ifr development code to change all its bad taste problems by changing all its structure. MVC architecture can also produce good code, but it is less stable and less conducive to long-term maintenance and iteration.
  • The complexity of DDD is due to a lack of domain modeling experience. If you’ve already absorbed enough boundary context summarization of the same requirement in MVC, switching to DDD now allows you to develop code faster.
  • DDD is not all engineering model structure is complex, DDD is the guiding principle, you can in the DDD four-tier architecture because of the introduction of RPC to dismantle the layers of each module, or because of the size of the business in medium and complexity without the introduction of RPC framework, DDD will be shorter and more concise. Compared with MVC, the interface is defined in the domain layer, the code is implemented in the domain layer, and the data is processed in the warehouse layer. Reference code: github.com/fuzhengwei/…