It has been 8 months since I got in touch with DDD, and the project I am maintaining is also developed based on DDD idea. From the beginning, I didn’t know how to start, to now I have learned a lot with ease, but only some keywords and scattered knowledge. At the same time, I also feel that because I am more and more familiar with the project. Practice makes perfect, so I can fulfill business requirements without thinking too much. I gradually realize that it is very necessary to learn DDD.

In the traditional development model, the product manager after the business needs to communicate with business experts, to abstract and to convey the results by oral or project management tools to the developer, the developer according to the transfer of the business needs of the mechanical product manager to function development, this pattern makes developers do not have a true understanding of the business principle, It is difficult for the developed functions to meet the requirements of the business side, and even if they do meet the requirements, it is difficult to cope with future business changes.

If everyone uses DDD to develop, business knowledge can be passed on well, because DDD encourages developers, product managers, and domain professionals to discuss, digest, and thoroughly understand business principles.

Here are some notes I took while learning DDD, organized into a mind map, so as to form a good structure of thinking, I hope to give you a deeper understanding of DDD.

The following content is excerpted from Domain-Driven Design and compiled according to my own understanding.

1.1 Elements of effective modeling

Model and reality binding

When developers and product managers discuss requirements, they sketch and write a few words on the sketch, which is the original model. The initial prototype was rudimentary, but it established an early link between the model and implementation, and we maintained that link through all subsequent iterations.

Build a model-based language

  1. Initially, domain experts had to explain business knowledge to developers
  2. Developers must also explain class diagrams to domain experts
  3. As the project progresses, both parties are able to use the terms in the model and organize them into statements that fit the model structure, and can understand each other without translation

Domain experts focus on business areas, developers focused on development, two people in different areas on the premise of not form a unified language is difficult to communicate, such as electric business domain experts concept, the performance of sell orders to have to explain what order is performed, the inside to developers have to translate all kinds of noun, if knowledge of domain experts and developers equivalence, We can understand each other.

Develop a knowledge-rich model

  1. Object has row and mandatory provisions
  2. A model is not just a data model
  3. Models should contain various types of knowledge

Refined model

As the model becomes more complete, it is refined, new concepts are added to the model, and concepts that are no longer used or unimportant are removed from the model.

Brainstorm and experiment

  1. The language and sketches, combined with brainstorming, turned our discussions into “model LABS” in which hundreds of variations could be demonstrated, tried and judged
  2. When the team walks through the scenario, the spoken word itself serves as a test of the feasibility of the proposed model, because when people hear the spoken word, they can immediately tell whether it is clear, concise or clumsy

1.2 Digestive knowledge

Effective domain modelers are digesters of knowledge

Modelers need to find the pieces of a large amount of information, and then constantly try to organize the information in various ways, trying to find the knowledge that makes sense for the large amount of information.

Knowledge digestion is not an isolated activity

  1. Usually led by a developer, a team of developers and domain experts work together.
  2. Gather information together and organize it into useful form by digesting it
  3. The original source of information comes from knowledge in the minds of domain experts, existing users, and experience accumulated by the technical team on related legacy systems or other projects in the same domain

The shortcomings of the traditional waterfall model

The business expert discusses with the analyst (product manager), who digests and understands the business knowledge, abstracts it and passes the results on to the programmer, who writes the software code.

  1. This approach has no feedback at all (the programmer does not contribute his own ideas)
  2. Analysts are solely responsible for creating models, but the models they create are based on the advice of business experts
  3. Analysts don’t learn from programmers and don’t get the experience of earlier releases
  4. Knowledge flows in one direction and does not accumulate

Domain experts work with developers to digest the benefits of understanding models

As all team members digest and understand the model together, their interactions change.

  1. The constant refinement of domain models forces developers to learn important business principles rather than mechanically develop functionality
  2. The process by which domain experts are forced to refine the important knowledge they already know is often the process by which they refine their own understanding, and they come to understand the conceptual rigor necessary for a software project.

summary

Developers, analysts, and domain experts should all input their knowledge into the model so that it is more organized and abstract and clean.

As the model continues to evolve, it also becomes a tool for organizing the flow of project information. The model focuses on requirements analysis, which interacts closely with coding and design.

1.3 Continuous learning

When we start writing software, we know very little

Project knowledge is scattered among so many people and documents with other useless information that we don’t even know what we really need.

Areas that appear to have little technical difficulty may well be an illusion — we don’t realize how much we don’t know. This ignorance often leads us to make wrong judgments.

All projects lose knowledge

  1. People who have learned something may go on to do something else
  2. Teams are broken up by restructuring, which results in knowledge being redistributed
  3. A critical subsystem that has been outsourced may only return code, but not knowledge

When using typical design methods, code and documentation do not represent this hard-won knowledge in a useful form. So if for some reason team members do not verbally transmit knowledge, then knowledge is lost.

Effective teams require a conscious accumulation of knowledge and continuous learning

For developers, this means developing both technical knowledge and general domain modeling skills. But it also includes studying the specific field they are working in.

Self-taught team members become the backbone of the team, tackling the most critical areas of development. The accumulated knowledge in the minds of this core team makes them more efficient digesters of knowledge.

1.4 Design with rich knowledge

  1. Business activities and rules are like the entities involved, but at the heart of the domain, any domain has various categories of concepts.

  2. The patterns produced by knowledge digestion can reflect the deep understanding of knowledge.

  3. As the model changes, developers refactor the implementation to reflect the model changes, so that new knowledge is incorporated into the application

1.5 Deep model

Useful patterns rarely stay on the surface, and as we learn more about the domain and application requirements, we tend to lose surface elements that seem important at first, or switch their perspective. At this point, subtle abstractions that were initially impossible to detect begin to surface, and they hit the nail on the head.

recommended

  • Share a Family Financial System (source code attached)

  • Recommend a set of open source general background management system (attached source code)

  • Recommend a cool monitoring system

  • Got 20 actual combat projects from my friends, quick leader!

  • Recommend a perfect parking management system, Internet of things project Springboot, attached source code

  • Recommend an Internet enterprise level open source payment system

  • A fairy to private work software, hanging to no!

  • Recommend 10 super practical enterprise open source applications!

  • Open platform SDK design practice!

  • “Taobao” open platform interface design ideas

  • Nine classic design patterns in Spring