[Architecture design] DDD Experience Sharing (Part 1)

Preface

As a developer, you should have heard of the terms "software development process" and "Domain-driven development. But... in my own words, developers thought that data files were written like tianshu, and it was too late to work under the pressure of a vague project.

 

Today, we are going to turn this impression around to help developers understand the "software development process" and "Domain-driven development" development technologies. In addition, it uses its own development experience to explain where and how these development technologies should be used. So that the development of the project is no longer out of nothing, but a gradual process that gradually grows.

 

* Before starting the article, you must first put forward the most important point: development technology is not the best but the most suitable. Hard-moving and teaching projects to your own team make the members very tired. This will not last long. For example, the software development process used as the topic of this article is also the result of adopting various technical data and being adjusted and integrated. According to the development habits of the team, integrating the strengths of various development technologies is a long-term path.

 

Definition

First, let's give a simple description and definition of the two development technologies to be explained today: "software development process" and "Domain-driven development.

 

"Software development process" defines "what to do 」

The "software development process" was proposed by someone else (I don't know who it is ...). Cut the work that should be done to develop a software into a group of software development stages with development priorities. There are many practical models for software development processes, such as waterfall and spiral.

 

A clearly defined software development process is like a sop for developers to refer. Let developers know what to do and what to do next in each software development phase. Focus on what to do and avoid thinking about divergence. Simply put, what is the definition of the software development process.

 

Domain-Driven Development defines how to do it 」

Domain-driven development was proposed by Eric Evans and the content was compiled into a domain-driven design. It defines a set of thinking logic for development, used throughout the entire software development process.

 

I believe that developers have used many development tools to analyze and design systems in each software development phase. For example, use case, category chart, sequence chart .... But to be honest, most of the data files only need to introduce how to draw a graph using XX tools at this stage. As for what to do after the picture is finished, how to concatenate the output in each stage. I have written many documents that I can't understand... I can say that most of the documents do not have the idea of putting all the work of the software development process through. Under such circumstances, each stage of output is fragmented and incoherent, greatly reducing the practical value.

 

Domain-driven development is to solve this problem. It defines a set of thinking logic for development and runs through each software development stage. Let developers know what to do and what to do next in each software development phase. To put it simply, how to define a domain-driven development.

 

Software development process-Example

Now you know what the software development process definition is and what the domain-driven development definition is. This article focuses on a simplified software development process and domain-driven development. Describes how these development technologies can be used together and how they can be easily and quickly completed. Next let's take a look at the definition of each software development phase in the software development process as described today:

 

Demand analysis phase (RA): what to do

The main task of the demand analysis phase is to collect customer requirements and define the scope of the project. Simply put, you must first understand what the entire project is to do.

 

System Analysis stage (SA): How to do it-Architecture Design

In the system analysis phase, the main task is to propose a solution to the customer's needs and analyze the system architecture. Simply put, it is necessary to make a preliminary decision on how to do it and design the entire system architecture.

 

System design time (SD): How to do it-Module Design

The main task of system design time is to design the objects of each function module for the system architecture. To put it simply, we need to make detailed decisions and analyze and design the functional modules in the system architecture.

 

Implement: Manual

The main task of the "System Practice Stage" is to convert the completed system architecture design into the actually executed program code. To put it simply, let's do it first, and implement the architecture modules designed and analyzed in the previous stages one by one.

 

The data listed above is a simple software development process used as the topic content. This software development process removes the technical details related to project management and focuses only on what developers should do. In this way, developers are expected to focus more on development-related knowledge. When developers have mastered the development work completed in each software development phase. You can get twice the result with half the effort by learning the software development process related to project management in the company.

 

After a brief introduction, developers should have a certain degree of understanding of the software development process used in this topic. In the subsequent sections, we will describe the content of each software development phase for this software development process.

 

Demand analysis phase (RA)

The main task of the demand analysis phase is to collect customer requirements and define the scope of the project. Generally, you can use tools such as cases and prototype to perform requirement analysis. Finally, the collected requirement data is compiled into a "Software Requirement Specification 」.

 

Of course... according to the actual situation I encountered, it is generally the business to interview customers on demand. It does not care about use cases, prototype, or other things, that is, simply sign the case first. A better business will organize a list full of functions. The worst thing is to say that the case has been taken down. All the subsequent work will be completed by developers to perform requirement analysis. In fact, no matter what you do, you still need to do the work, but who will do it.

 

For the demand analysis stage, we have mentioned that we will use tools such as use cases and prototype to complete the requirement analysis. These tools are powerful and can help capture customers' needs. However, the actual use of these tools will find that only the customer's needs are captured. You can only analyze and design issues based on the experience of developers.

 

There was a "qbq! The problem behind the problem is very red. It shows that the root cause of the problem is to be solved, rather than just dealing with the problem that appears on the surface. The same is true for customer demand interviews. Instead, we need to understand the domain knowledge of the customer's professional field, conduct interviews on the content of the project, and extract and encapsulate domain knowledge and define domain terms. Use these domain knowledge to understand and solve customer problems. In this way, we can truly propose the solutions required by the customer to solve the customer's problems. This is also the "Domain Model" concept proposed by domain-driven development.

 

Demand analysis phase (RA)-Domain Model

It is a domain model related to the access control system. It uses Abstract methods to describe the domain knowledge used in access control-related fields, as well as proprietary domain terms. We can look at the content described in this figure as follows:
-A card reader is installed on a door.
-A door can be used by several users.
-A card reader can control a door switch.
-A card reader has many card swipe records.
-A card reader allows several cards to pass through.
-A card swipe record records a card reader and a card.
-......

 

The establishment of this domain model is in the process of interview with customers. After understanding the domain knowledge of the customer's professional field, the process is finally drawn from the process of extracting and encapsulating domain knowledge and defining proprietary domain nouns. Through this abstract object model, domain knowledge in the customer's professional field is transformed into model data that can be discussed and recorded. In addition, this domain model is not an independent work project. It must be integrated with data such as use cases and prototype. The domain model must be used for a complete explanation, and the use cases and prototype data must be recorded in interviews with customers. For example, if a use case records the customer's intention to "set the user through which door", the abstract description can be found in the domain model through the abstract object model: 「 the user has a card which can be used to open the door with a card reader and then pass through 」. When the domain model can pass all use case tests, the correctness of the domain model is verified. Developers can safely bring the domain model into the next development stage.

 

To be continued...