By participating in the field drive design Congress with what you think

Author: Xiao Cheng Story more

Links: http://www.jianshu.com/p/2223a7508683

Source: Pinterest

Copyright belongs to the author. Commercial reprint please contact the author for authorization, non-commercial reprint please specify the source.

2017 The first field-driven technology conference has always been my great expectation, I would like to thank the right to give the tickets can let me enjoy the assembly style.

The organizers of this Congress are very attentive, organized a lot of topics to explore, indeed the content of the Conference has brought me the feeling is shocking, my previous knowledge of the field only from "domain-driven design" and "drive the field Driven design" two books have studied, and in the implementation of the micro-service ecosystem has had some contacts.

In the whole process of the General Assembly, listening to a lot of teachers of different topics of speech, I was very impressed by the Zhang Yicheng teacher 's "bounded context of practical significance", Tengyun Teacher's "ddd-not so difficult." I will now talk about some of my own ideas in conjunction with these two topics.

the practical significance of bounded context

(The photo may not be clear because of the light and distance, I hope you forgive me)

First, let's explain what a bounding context is.

Implementing domain driven design explains that the bounds context is an explicit boundary, and the domain model exists within the boundary. Within the boundaries, all terms and phrases in a common language have a specific meaning, and the model needs to accurately reflect the common language.

Describe it in a more figurative language: we go to work every day, when we commute to the subway, I get off line Line 8, transfer to line Line 2, and then transfer to line Line 10, so that I can finally reach a certain location and end the process. In this process, lines Line 8, Line 2 and Line 10 can all be understood as different gauge contexts, and our intermediate transfer actions can be understood as domain events, and our ultimate goal is to work, which is the key event, and we work in different contexts to switch.

We can also understand the context as a module, a system, an application, or a service. In my opinion, the existence of the clearance context on the division of MicroServices is of great significance, but the boundary is not a new concept, as early as in the SOA era has existed, but at that time in the enterprise application is not the SOA and DDD too many links together, do not know how many students know the Banqiao (Peng Yang), The relationship between SOA and DDD has been explained in his JSON website as early as 2008:

The SOA service is packaged again after the loose-coupling component is detached, while Evans DDD is a razor that shuts down the component relationship. From this perspective, DDD should be a more basic platform, high-rise flat, and DDD is the object methodology, set analysis mode and design mode
----from SOA and DDD

It is not difficult to see through the articles and explanations of the time that the fact that in SOA is more of the use of DDD OO to replace the database analysis design, SOA is coarse-grained service packaging, and DDD is a cut of coarse-grained blade. As the General Assembly Zhang Yicheng teacher a joke said, is because the micro-service to save DDD, through this sentence can be seen that the proposed micro-service is really to combine the DDD, and micro-service of the fine-grained service and DDD itself concept is also fit, so as to achieve the realm of mutual development.

In this speech, Zhang Yicheng in-depth discussion of several key words: Conway's Law, logical boundaries and physical boundaries, cut off the coupling of the database, the method of identifying the context, and so on, can obviously feel, DDD also in the development and micro-services and the Internet in the field of continuous evolution.

Ddd-'s not that hard.

Tengyun Teacher's share more is in the practice process summary, first talk about data-driven and domain-driven differences, the table is as follows:

Data-driven	Domain Driven
Database First	Domain Model First
Algorithm and data mechanical combination	Organic combination of algorithms and data
Technology-oriented	Business Orientation
Code does not reflect business	The code is the design
Business logic Dispersion	Business logic cohesion
Poor extensibility	Good extensibility

I remember before 2010, research and development personnel and products after the first step is to use PowerDesigner Drawing database table structure diagram, according to the database table structure diagram backward project architecture, after DDD began to promote, slowly from the UML diagram began gradually occupy the dominant position, Now the table chart has become a complement to the architectural design.

There are two common design models in DDD, namely, anemia model and congestion model.

Anemia model
Anemia model refers to the domain object only get and set methods, contains only the state (attribute), does not contain the behavior (method), in this design, the need to separate out the DB layer, specifically for database operations.

As you can see from the diagram, the role of the domain layer is weak, and the domain object is simply the object used to serve as the data store.

But the overall architecture of this model is clear, one-way connections from top to bottom.

Domain Layer--DAO--database, service services, remote access interface----facade interface

Congestion model
The congestion model is a relative definition of the anemia model in which the domain layer is not a collection of get and set methods, but rather integrates some business logic with persistent operations, as shown in the following figure:

The call relationship of this model becomes: Application Layer--facade interface---Infrastructure layer

In fact, the advantage is that the business logic that is equivalent to the domain object is encapsulated inside the object, and the biz or service layer only needs to invoke the object for a simple business assembly, unlike the anemic model, where all the business is concentrated in the Biz layer or service layer causing very heavy and difficult to split, But the congestion model is difficult to design, need to have some experience in the early planning of the designer, later work can be more effective, otherwise it will cause confusion.

In the sharing of the cloud teacher also did the entity and value of the object of the explanation, the following I will be the difference between the table is listed in the form for reference:

Entity	Value Object
Has a life cycle	Play a descriptive role
has a unique identity	No unique identification
Determining Equality by ID	Implementing the Equals method
Additions/deletions/re-search/persistence	Instant creation run out and throw it
Variable	Not variable
Like Order/car.	Like Address/color.

To see here reminds me of a story:

There were twins, and they were born exactly the same, so that their parents couldn't tell, but they had to tie a necklace around the neck of the twins to mark: who was the boss. Who's The dick? In fact, this "mark" can be regarded as the identity of the entity, but is marked with a necklace.

One day the small town to count the distribution of twins, then investigators came to their home, asked their parents: "You have twins in your family." A couple of twins. Dragon and Phoenix tires. Still is... And then their parents reported, "twins-two boys," and the investigators took notes and went. In the process, they did not mention the "necklace" on the neck of the twins.

This is the fundamental difference between an entity and a value object: An entity needs to know not just what it is. And you need to know which one it is. The value object just needs to know what it is.

Summary

The night has been deep, the article wrote here, I think should also be able to end, the content of the conference is very rich, here just to see me, hear, combined with some of my own ideas summed up, the article will inevitably some places to compare the surface also hope everyone haihan.

Reference Articles

http://raychase.iteye.com/blog/1328224
Https://www.cnblogs.com/xishuai/p/ddd-entity-value-object.html

Super good news. Zhang Yicheng teacher will be launched in Chengdu, the field drive design Open class, two days of courses, 4 units, from the understanding of the field-driven design, strategic design, tactical design to the field modeling practical training, hands-on teaching you to enter the field drive design Hall.

Please click to read the original text for more details

(The above image is from the DDD Domain Modeling Summit, the copyright is owned by the organizing Committee)