What is "domain-driven design"

The Domain-driven design ("DDD") by EricEvans is a classic concept. Although the concept of "Domain" has long existed, however, this book makes it possible for people to carefully examine the construction of software. I believe that after reading this book, you will truly appreciate the power of the field, this power determines the final value of the software.

Domain-Driven Design ("DDD") by Eric Evans is a classic concept. Although the concept of Domain already exists, however, this book makes it possible for people to carefully examine the construction of software. I believe that after reading this book, you will truly appreciate the power of the field, this power determines the final value of the software.

Domain meaning

Simply put, each software program is related to the activities or interests of its users. The main environment in which the program is used is called the "field" of the software ".

Various business logics in the field constitute a variety of software activities. For example, in the banking and financial system, domain logic involves operations such as account opening and transfer. You may say that common programmers seldom come into contact with the banking system. This example is not simple enough. let me give you a more common example. all programmers should have been in touch with the article management system, the operations in it, such as top placement and refined addition, are domain logic. In this case, it seems that the action corresponding to the use case is domain logic, but the answer is No. for example, saving articles in the article management system is often not domain logic, because it is only a persistence-related action, it is purely technical implementation, but the deposit in the banking and financial system is generally classified as a domain logic, because it is what we often call deposits, has a clear business meaning. Seeing this, we seem to have some Faint. here we will provide a rule to determine whether it is a domain logic: whether this logical action has a clear business meaning or whether it is business-related, it's not just about technology.

Only the technical implementation means can be removed from the domain issue to ensure that the domain itself is refined, so that programmers can concentrate on the domain issue itself, rather than being full of technical implementation means.

Composition of fields

According to Eric, the role composition in the field is generally divided into the following five types:

• Entity: an object with a unique identifier.
• Value Object: the Object without a unique identifier.
• Factory: defines how to create an object.
• Repository: manages entity sets and encapsulates their persistence processes.
• Service: operations that cannot be assigned or encapsulated on a single object.

Field thinking

Next we will discuss the five role fields one by one.

The concept of entities is well understood. There are many such examples. for example, everyone can be seen as a "different" entity, the reason why I use the word "uniqueness" is to emphasize that the entity must be uniquely identified. even if we think of identical twins, they can be separated by some identifiers, for example, you may raise your fingerprint. what if you have no hands on the disabled? In this way, we can also use DNA Detection. of course, these are all just a joke. in actual programming, we generally use an auto-increment number as the identifier, for example, you can use the auto-increment field of the anto_increment attribute when saving objects in the MySQL database. It should be noted that if you want to determine whether the two entities are equal, you cannot judge based on the attributes of the entities. you must absolutely rely on the entity's identity. even if you were in height ten years ago, weight, age, and many other important attributes change more or less, but you are still you, because your DNA will not change because of these attributes, if the variation of your DNA occurs during this period, it is unexpected. These seem to have some philosophical taste.

The meaning of the value object is relatively vague compared to the object. many people prefer to call the data transmission object a value object (the data transmission object is different from the value object we mentioned here) this gives people a lot of ambiguity in their understanding of value objects, and the examples of value objects are not as straightforward as the objects. Literally, the value object does not have a unique identifier. In most cases, the value object remains unchanged. Therefore, the system does not need to track them in real time and instantiate a value object, if you don't need it, destroy it. but when do you use a value object? Which attributes are classified as value objects? What is the role of a value object? These are all worth considering. Generally, when we perform domain modeling, we prioritize the unique identifier and the information that is often used to retrieve objects as the attributes of objects, while other information is divided into other entities based on relevance, it can also be divided into value objects. for example, in a CMS system, for an article entity, the article number and the article title should all be attributes of the article entity, for the start time of the validity period of an article, the end time should be placed in an independent value object, where only the start time or end time is used, or both the start time and end time exist or do not exist at the same time, which indicates different logic meanings. the rational use of value objects is helpful to shield the complexity of some related logic, you can also keep the object concise.

The factory is much easier to understand than the former two. after all, the name can reflect its responsibilities, that is, to create an object. Since the object is created, can we instantiate one directly? A simple scenario is acceptable, but factories often bring huge benefits. Simply put, they block the complexity of object creation. A group of related objects should be considered as a whole, access to any of these objects should also begin with the overall "root" (usually the most important entity as the root). Therefore, complicated Association will inevitably make the creation process as complicated, can we assemble objects in the constructor of the "root" Object? in simple cases, complicated and inappropriate, such as assembling a car, it is usually done by the assembly worker and robot in the factory. if we complete the assembly in the "root" constructor, it is similar to the assembly worker and robot in the car, this is of course unnecessary. Once a car is assembled and manufactured, it is unnecessary to assemble workers and robots.

The concept of warehousing is similar to that of data access objects (DAO), but not the same. a big difference between the two is that warehousing has the concept of "root, data access objects are usually divided by database tables. The main purpose of using warehousing is to query and persist objects in the domain, and there are often complex aggregation relationships between objects in the domain. to ensure the invariant, the root concept is introduced, access to a sub-object in a domain object must be directed by the root. This may not be easy to understand. I would like to give a simple example: cars and tires can be regarded as the aggregation of objects in the field. cars are the root of the aggregation. if we want to access tires, it must be done through the car navigation. why? because there is a constant between the car and the tires: A car has four tires. if the client is allowed to directly access the tires, it is difficult to ensure that the logic is not broken.

The term "service" has been used many times. However, most of the services mentioned previously are technically specific and belong to the application layer in terms of hierarchy. Generally, it is something like sending an email after registration. the service in the domain-driven design is not the concept of this category. it emphasizes the relationship between entities, instead of purely technical means. For example, in the CMS system, if an article is added to the essence, the author's experience is plus one. This logic involves two entities: article entity and author entity. The logic of experience value plus 1 is redundant both in the article entity and in the author entity. Therefore, it is necessary to abstract a service layer on the entity for processing. Someone may ask: can we put this logic on the traditional application layer? In most cases, this logic belongs to the domain logic rather than the application logic. if it is placed at the application layer, the domain logic is leaked, and the domain layer becomes a decoration, however, there are also exceptions. sometimes it is difficult for us to identify whether a logic is a domain logic or an application logic. it is no problem to add this logic to the application layer at this time, if it is found that it is more appropriate as the domain logic in the future, it will not be too late for reconstruction.

Interview with Eric Evans: Why is the latest development of domain-driven design always important?

Basically, domain-driven design is the guiding principle that we should focus on important issues in the fields of users' interest. Our wisdom should be used to understand this field, and other experts in that field abstract it into a concept. In this way, we can apply this abstract concept to construct powerful and flexible software.

It is a guiding principle that will never expire. It is useful whenever we operate on a complex field. The general trend is that software will be applied to more and more complex problems, and more close to the core of the business. For me, this trend seems to have been interrupted for many years, because Web suddenly appears in front of us. People's attention is removed from logic-rich and difficult solutions, because there is too much data to be transferred to the Web, just simple actions. Because too much data needs to be transferred, it is difficult to do this simple thing on the Web within a short time, so it consumes all the capabilities of software development.

But now, people have made great strides across the basic layer of this Web application and have concentrated their attention on the business logic.

Recently, the Web development platform has gradually matured, which is sufficient for the application field-driven design for Web development. There are many positive signals, such as SOA. if the application is good, it can provide us with a very useful method in the field of resolution.

At the same time, the agile process has enough influence, and most projects now realize the importance of iteration, close collaboration with business partners, continuous application integration, and work in a strong communication environment.

Therefore, domain-driven design will become more and more important in the future, and there are already some foundations.

Technology platforms, such as Java,. NET, Ruby, and others, are constantly changing. How can the domain-driven design adapt to this situation?

In fact, new technologies and processes should be verified by whether they support teams to focus on their fields, rather than ignoring them. Domain-driven design does not depend on a specific platform, but some platforms provide more good methods for creating business logic, and some platforms are more focused. The development in recent years shows that a platform that provides methods for creating business logic is a promising direction, especially in the terrible late 1990s s.

Java is the default choice in recent years. from the perspective of expression, it is a typical object-oriented language. For Distracting Clutter, basic language is a good choice. It has the garbage collection function, which has proved to be useful (this is more useful than C ++, which requires a lot of attention to the underlying details ). Java syntax is messy in some places, but POJO (Plain Old Java Objects) can still be designed to be understandable. Some innovations in Java 5 syntax improve code readability.

However, when the J2EE framework came out for the first time, it completely drowned those basic expressions in a large number of framework code. Generates terrible and bad objects based on earlier contracts (such as EJB Home, Get/Set prefix access for all variables. This tool is so cumbersome that the development team has to do its best to make it work. In addition, it is very difficult to change objects. once a large amount of code and XML are generated, people are often helpless. It is difficult for such platforms to develop efficient domain models.

In addition, the first generation of tools were used to barely develop the Web UI through Http and Html (not designed for this purpose. At that time, it was so difficult to create and maintain a decent UI that few people paid attention to the design with complicated internal functions. Interestingly, at this moment, the object technology emerged and solved the problem of complex modeling and design.

This is also the case on the. NET platform. some things are better handled, while others are worse.

It was a depressing time, but there have been some changes in the past four years. First, let's look at Java. There are new ideas on how to selectively use the framework community. many new excellent frameworks (mostly open-source) have also emerged. For example, frameworks such as Hibernate and Spring can use a more lightweight method to handle the specific work that J2EE has attempted to do. It is more convenient to try to solve the UI problem like AJAX. Today's projects are smarter when choosing to use new J2EE items that provide both value and hybrid. The term POJO is generated at this time.

The result is that the technical contribution of the project is gradually reduced, and significant progress has been made in isolating the business logic from other parts of the system, so that the logic can be written based on POJO. This will not automatically generate a domain-driven design, but it provides a viable opportunity.

This is the Java world. Then there will be new people like Ruby. Ruby has a strong expressiveness syntax. at this basic layer, it will be a good language for domain-driven design (although I have not heard of any practical cases in those applications ). Rails brings a lot of excitement, because it eventually seems to make Web UI development as simple as developing Web UI before Web appeared in the early 1990s s. Soon, this capability was widely used in the construction of many Web applications without many background fields, because it was very difficult to develop these simple applications in the past. But my hope is that when the UI implementation in the problem is partially reduced, people can regard this as an opportunity to focus on the field. If Ruby is used in this direction, I think it will provide a great platform for domain-driven design. (Some infrastructure may be added in)

More cutting-edge topics occur in the domain description language (DSL) field. I have always believed that DSL will be the next major step driving the development of design in the field. Now, we don't have a tool to really give us what we want. However, people have done more experiments in this field than in the past, which makes me hopeful about the future.

Now, what I can say is that most people who try to use the domain-driven design are based on Java or. NET platforms, and a small part of them are on Smalltalk. This is a positive signal in the world of Java with direct effects.

After you write this book, what are the things worth noting in the field-driven community?

One thing I'm very excited about is that people adopt the principles I mentioned in the book and then use some methods that I did not expect to practice. For example, the use of strategic design in the StatOil project of Norwegian National Petroleum Corporation. An architect wrote a report based on his experience.

In other projects, some people have made context ING and applied it to the evaluation of existing software when choosing whether to build or buy it by themselves. It is worth mentioning that some of us have explored this topic by developing basic domain objects used in many projects.

We have been exploring how far this domain descriptive language can be pushed when we are still using Java to implement objects.

It has gone far. I am always grateful when people tell me what they are doing.

Do you have some suggestions for those who want to learn how to drive design?

Read my books !; -) In addition, you are willing to invest time and money in the project. One of our initial goals is to provide a good case for people to learn through it.

Remember that domain-driven design is mainly performed by teams, so you may want to become a Evangelist. In reality, you may need to find a project that everyone is working on.

In addition, you must pay attention to the following important aspects of modeling (Pitfall ):

Focus on practice. The model requires code.

Focus on specific scenarios. Abstract thinking needs to be implemented in specific cases.

Do not try to implement domain-driven design for everything. Draw a range table and decide which domain-driven designs are required and which ones are not required. Do not worry about things beyond the boundary.

Keep experimenting and expect errors. A model is a creative process.

This article is available at http://www.nowamagic.net/librarys/veda/detail/1186.