Agile design and field-driven design

Agile design and domain-driven design are two dimensions. Agile development is a design concept, while domain-driven design is only a specific design method for organizing business logic. There are other design methods for organizing business logic, such as process-oriented design, table module design, or similarJava BeanAnd MicrosoftDNABusiness Logic organization design. Domain-driven organizations have great advantages in organizing complex business logic and responding to changes in business logic, and have gradually become the mainstream organization business logic. At the same time, the advantages of field-driven design also make it the first choice for Agile design.

 

 

 

 

What are the advantages of domain-driven design over traditional business logic organizations? Do you know data-centric system development? Now in mostProgramMembers should have gone through this stage, because the field-driven design was first proposed in this century. This idea has become popular in China.04Years later, because most of the books on field-driven design were translated to China after 04 years later, few people can understand this idea through the Internet and English documents.

 

Think about the process we developed before. Basically, after the requirement is divided, we start to create a data table, then create a data model based on the data table fields, and then start to write the data persistence layer, logic layer and UI Layer. I think most people should have such experiences. This development idea is a typical data-centric development idea, and the important business logic must depend on the database table structure. This development method has many drawbacks, for example, it is difficult for many business logic to be extracted independently from the database. When the database changes, the business logicCodeAlso change. This seems to be a bit dependent on Inversion. Originally, the database's responsibility is to store domain data. It should be because the database depends on domain logic, but now the domain business logic is dependent on the database.

 

If you have never understood the domain-driven design, try it. However, many people may have used this development design idea, but do not know these names. There are many such examples and there are many design patterns that I have used before I know his name and a design pattern.

 

The most important part of the domain-driven design is the domain logic and model as the core, and the entire system is centered around it. There is a persistence layer between the database and the domain model to map the domain data and the data table. In this way, the Object-Oriented Domain Model and the structure-oriented data table are associated through this persistence layer. It is not the opposite to allow the database structure to depend on the domain logic.

 

What are the benefits? This should begin with how the domain model organizes the business logic. The domain-driven design advocates taking the user's business logic as the core, and the specific implementation technology is only an auxiliary part. The terms, concepts, and relationships that appear in users' business needs must be modeled in our system. All the actions and attributes of these models are defined in the model.

 

In short, when the domain model is established, the entire domain model should be organized into a complex large network, and these models and network relationships can correspond to the actual business logic concepts and relationships of users one by one. This method has great advantages, so that we can easily capture user needs and make a series of applications based on these models.

 

No matter how users change, they will not make major changes at their domain model level. Unless their actual business logic changes significantly. In this case, our system will certainly undergo major changes, and the project funds and cycles need to be increased. In this case, users are generally able to understand and accept this, after all, their own business logic has undergone major changes. However, if the user's business logic is slightly changed, or the user just wants to improve the operation habits of a system UI, I don't think this will involve major changes to our core domain model. And the user must be satisfied.

 

When the user's business logic changes, our domain model library should also change and be consistent with it. This is the best way to ensure that the system can quickly respond to changes.

 

when you propose a small or superficial change, you need to make a big effort, and even have to tell the user that this cannot be changed. Is it embarrassing for you to influence too many things?