I have been studying dome-driven design (DDD for short) for more than half a year. I got to know DDD for the first time because I knew what the hyperemia mode was and what the anaemia mode was, and then I started to touch ON DDD along the way. It was a strange feeling that I didn’t know DDD until now. When I was growing up, I kept trying to solve it, and finally with the help of DDD, the cloud was lifted. My question, the first point is that is it really right for us to adopt the development model of Controller->Service->Dao, the Service layer plays the God class, all logic is jammed in, this model causes the infinite expansion of the Service layer, obviously the answer is not correct, In fact, many people are still indifferent to this, but how can we improve it? In college, before he has been doing to find their own outsourcing project, used to put down the rhetoric to oneself, more complex system, as long as the disposable does not require to maintain and change, as well as its demand, I can do it, because this kind of development mode, is indeed the CURD performance incisively and vividly, a senior engineer code implementation results, A rookie can do the same (this is the result, not the process, but the process could be the same, which is painful). The second point, is also the continuation of the first point, with rich experience, and began to understand object-oriented software engineering, so the question comes, in the traditional development mode, is embodied in the object oriented, we learned the design pattern, where is the practice, but in fact we are often hang sheep head sell vinegar, sheep head is object oriented, Dog meat is process-oriented.

Next, I will guide you into the DDD mode of thinking bit by bit, we will be used to the development of process-oriented development and DDD advocated model-oriented development contrast, gradually into the object oriented. Note that this article only tells you what DDD is and the benefits and drawbacks of DDD; how to practice DDD will be explored later. DDD proposes a so-called domain modeling, which is essentially a single responsibility for classes in object-oriented development principles, and our first problem is what to do with the Service God class that takes on too much responsibility. One word is very easy to solve, is to disassembly, I have tried to follow the guidance of the single responsibility of the class, inject a dependency into a Service class too many other classes, there may be a dozen or twenty readers you can check your own project, this is bad code, this brings only the benefits of function points encapsulation, It does not solve the problem of preventing Service class bloat, it will continue to bloat, and it is still process oriented development. The other problem is that even if this approach solves the problem of Service class bloat, it does not solve one of the key things, namely, the code is not business. What is not reflected in the business? For example, activating users, how do we develop?

public class UserService{ public void updateAvailableById(long id,boolean available){ userDao.updateAvailableById(id,available); }}Copy the code

This is a typical process oriented development code, everywhere in our project, the loss of the object in the object oriented concept, now we are in the development, instead of being constrained by using the database of our thinking, we received the demand for the first time, on the analysis of the design phase, often is the data table analysis as the core design, Is first given data table name and field according to the demand, then training programmers learn SQL statement how to operate the data table, then the programmer for the realization of the data table sequence of operation, the process will inevitably will code written style, with the core analysis data table design, the code is hard to avoid is not evolved into procedural code, Because we’re focusing on manipulating a table, and a field associated with it. This is the anaemic model, where the UserDao is a collection of SQL statements about the user table, represented in the project as a bunch of SQL statements, and the UserService is the entry point to the Transaction Script along with the miscellaneous Service classes. The user object never appears during this entire process. Domain-driven advocacy is as follows.

@Data
public class User{
    private Long id;
    private Boolean available;
    public void activate(){
           this.setAvailable(true); Public class UserOperationService{@autoWired private UserRepository UserRepository; public void activate(User user){ user.activate(); userRepository.save(user); }}Copy the code

First is rich in the first point is such behavior (i.e., congestion model), which is advocated by the real object-oriented development, business system point of concern is a business function rather than thinking about how we should build table, this function how to write SQL statements, has always been our thinking has been kidnapped by using the database, one begins to build table write code, code is redundant, It’s a completely procedural way of thinking that ends up making the system very difficult to maintain. DDD refers to a Repository, not a DAO. DDD refers to a Repository, not a DAO. DDD refers to a Repository, not a DAO. What you need is what you get, and you don’t have to worry about what’s behind it, whereas daOs have to worry about how SQL statements are written. Go ahead and read this article to think more deeply about objects and the natural impediments of databases, and leave questions in the comments if you’re still confused.

We should not put the behavior methods that belong to the domain model into services. Objects not only have properties but also behavior. Data and behavior are encapsulated together and mapped to business objects in the real world. Going back to what we were taught when we first learned about object orientation, that everything is a class, not just a God class, we need to create more classes with proper logic, each with a clear division of responsibilities, so that the logic is scattered among the appropriate objects. Such objects are called “congestion models”, and this process is also called domain modeling, which is the essence of object orientation.

At this point, you may have some doubts about the above example. 1. “How can such a simple function be so complicated in DDD mode?” 2. “What you said is to use The ORM framework Hibernate.” 3. “But isn’t it all about adding and deleting data?”

First, why is DDD called the way to design complex software? Because the system is complex enough to fully show the effect of DDD, business logic on vertices that modify the extension of any business logic can do punches have means to resist, greatly reduces the first contact with colleagues, to fit the threshold of the system and better avoid exist hidden bugs (because you always accidentally changed one line of code, The result is a business exception). Simple system functions, only simple add, delete, check and change, all business logic in fact only simple increase and query, it is impossible to extract the domain model, if the direct use of DDD all theory, in fact, it is a waste of time, kill chicken with a sword. However, there is no permanent code, and refactoring is always along with the evolution of the entire system, so the recommendation is that even simple systems should be built with DDD in mind from the beginning. I will continue to write several articles summarizing my practice of DDD theory.

For the second point, I recommend you to read the ORM thinking of domain-driven Design (DDD) in this article. If you still don’t understand, please leave a comment in the comments section. In fact, the purpose is to avoid data modeling, data modeling, database technology kidnap object-oriented development ideas, virtually lead to the development of the first output table design, and ignore the original model design, to form a habit of thinking, “you are not good design table ah”. Hibernate is actually designed under the guidance of JPA theory in DDD to make developers more focused on business logic implementation and domain modeling.

There is also a problem that many people have been using the wrong ORM framework like Hibernate, I suggest you go to read this article how to choose the technology of JPA or MyBatis

Third, a preliminary understanding of DDD and wants to expand the practice, this doubt does exist, DDD difficult in point is that he needs to shift your thinking, you don’t need to start to pay attention to the database, not to care about SQL statements, from data modeling to domain modeling, and the process will you again the thinking of object-oriented car function board exposed, I’m very sorry, You haven’t been developing with object-oriented thinking for a long time. Alistair Cockburn proposed the hexagonal architecture to solve the problems caused by the traditional hierarchical architecture. It advocates shielding technical details and emphasizing business logic, with the ultimate goal of realizing reusable business logic and organizing it into a reusable self-enclosed business model, that is, copying does not go out of shape. If you think about it, the biggest disadvantage in anaemic mode is that the business logic is not reusable, it is not organized into a reusable self-enclosed business model.