Field-driven development (1)-different development modes

Document directory

• Cashier business scenarios:
• Cash register business use cases:
• Cashier Business Process:

I have heard that ddd-"domain-driven development" has been around for a long time. Many Daniel in the garden has written a blog introduction, but I have never tried it until a database transplant occurred in a company project this year, the original business logic was written in the storage process of sqlserver. Now we have to port it to PostgreSQL to realize it. We can continue to adopt the "table-driven development" model, and there is no future. So it took a few weeks to practice the development model of domain-driven development.

With the consent of the author of "Object-driven development in the field: Come on, let's start with the object", I chose the "Supermarket cash register" business scenario in the article, developed a "Supermarket Management System"-PDF. net supermarket mis. Here is. This series will explain the technical details of this development process, but as the beginning of this series, I will first talk about the Development Mode driven by the field, which gives me a different feeling.

 

Domain-driven development model 1. Analyze business needs.

The supermarket management system includes cashier management, commodity management, equipment management, employee management, and customer management. The cashier management includes cashier management, cashier management, and cashier management; commodity Management includes basic commodity information management and commodity inventory information management. device management, employee management, and customer management are both auxiliary and simple. The core of the system is the "Cash Register process ", note that it is "process" rather than "management". When talking about management, it is easy to fall into the "Management System" idea and say "process" is more likely to be followed by business scenarios and business use cases, business processes.

Cashier business scenarios:

After the customer buys the product, they come to the cashier. The cashier checks and scans the product. The cashier displays the price list of the product. The cashier notifies the customer of the total price of the product, confirms the customer, pays the payment, and completes the cashier.

Cash register business use cases:

There is no strict distinction between "scenarios" and "use cases". I think "Use Cases" are more technical words. In this example, there are some roles, such as customers, cashiers, cash registers, and some objects, such as products, shopping carts, price tickets, and activities, such as scanning commodities (Reading bar codes ), calculate price and pay.

Cashier Business Process:

Everyone has been to the supermarket, and the process is simple, but it is very complicated in professional terms. Here I leave my work alone.

 

2. design domain object model

In the article "Object-driven development in the domain: Come on, let's start with the object", the author has already provided the object model in the domain, which is not repeated here, however, the model I designed is slightly different from the original author. I will discuss it later.

 

With the domainmodel, you can test the domainmodel before the system is fully developed to verify whether the core logic design of the system is reasonable.

3. Test the domain object model

Why this step? Because we have obtained our domain object model after the previous business analysis, is our understanding correct? To verify that our understanding is correct, we need to test the model in step 2 to see if it is correct or reasonable.

 

Static void testmodel ()
{
// Http://www.cnblogs.com/assion/archive/2011/05/13/2045253.html

// How many items do we create?
Goodsstock redwine = new goodsstock () {goodsname = "red wine", goodsprice = 1800, goodsnumber = 10 };
Goodsstock condoms = new goodsstock () {goodsname = "condom", goodsprice = 35, goodsnumber = 10 };

// Create several customers
Customer chunge = new customer () {customername = "Chun ge "};
Customer beianqi = new customer () {customername = "beianqi "};
Customer noname = new customer ();

// There is a cashier
Cashierregistermachines crmanchines = new cashierregistermachines () {cashregisterno = "cr00011 "};
// Of course, we need the cashier.
Cashier cashiermm = new cashier (crmanchines) {cashiername = "cashier mm", worknumber = "syy10011 "};

// The customer starts queuing for checkout.
Queue <customer> customerqueue = new queue <customer> ();
Customerqueue. enqueue (chunge );
Customerqueue. enqueue (beianqi );
Customerqueue. enqueue (noname );

// The team comes over and receives cash in order
Foreach (VAR customer in customerqueue)
{
// Cashier
Cashiermm. cashregister (customer );
}

}

 

Iv. design business processing

When we compile a test case for a domain object model in step 3, we are actually testing the business scenario. The code for processing the business scenario is almost "business processing class"-biz class, we can extract it and complete it to get the real service processing class. This business processing class will be improved in the future, but it has been basically formed here.

 

5. Design entity and viewmodel

When improving the business processing class, we need to analyze which domain object attributes need to be persistent. Be sure not to analyze a single domain object, but to analyze it according to the object model of the entire domain, for example, two domain objects may use a persistent attribute. In this case, we should consider placing this attribute in an object, in this way, we get the entity class required by the system. We can analyze the attributes of objects in the fields that need to be used by the user interface (View) for the same reason, the attributes of multiple domain objects may be combined to a user interface, so that we can get the viewmodel.

To put it simply, entity and viewmodel depend on biz class and Biz class to schedule domainmodel and use or generate entity and viewmodel.

Biz is like a business case. It combines the call of momainmodel. Here, this biz may be more like a service. Only entity in the system will be handed over to the database.

 

Entity

 

Viewmodel

Vi. Test business processing

We have tested the domain object model in step 3. At that time, the data was simulated and the database was not used. Now we have written some test cases for real testing. You can use the unit test that comes with vs to do the test, or write a special test project, or directly write a simple test page. Because the "domain object model" has been tested, this step tests whether our business operation class can correctly manage domain objects and generate viewmodels.

 

Static void testbiz ()
{
// How many items do we create?
Goodsstock redwine = new goodsstock () {goodsname = "red wine", goodsprice = 1800, goodsnumber = 10, serialnumber = "j000111 "};
Goodsstock condoms = new goodsstock () {goodsname = "condom", goodsprice = 35, goodsnumber = 10, serialnumber = "t213000 "};

// Create several customers
Customer chunge = new customer () {customername = "Chun ge "};
Customer beianqi = new customer () {customername = "beianqi "};
Customer noname = new customer ();

// There is a cashier
Cashierregistermachines crmanchines = new cashierregistermachines () {cashregisterno = "cr00011 "};
// Of course, we need the cashier.
Cashier cashiermm = new cashier (crmanchines) {cashiername = "cashier mm", worknumber = "syy10011 "};

// The customer browsed around and selected the desired product.
Chunge. likebuy (redwine. Takeout (1 ));
Beianqi. likebuy (redwine. Takeout (1 ));
Beianqi. likebuy (condoms. Takeout (1 ));
Noname. likebuy (condoms. Takeout (2 ));

// Call the cash register business class
Cashierregisterbiz biz = new cashierregisterbiz (cashiermm, crmanchines );
Biz. addqueue (chunge );
Biz. addqueue (beianqi );
Biz. addqueue (noname );

Biz. cashierregister ();

}

 

7. design the table architecture with the entity object, you can naturally get the script for creating a table in a specific database system. The supermarket management system uses the object class in the PDF. NET Framework. The ing between the attributes of the object class and the field of the table is very clear, so you can directly obtain the script for creating the table from the object class. Run the table creation script of the system, so that our database is ready and the system can run.8. Development user interface

I have finally waited for this step. Many times I want to directly step through the first seven steps and do this step first. However, to practice the "Domain-driven development" mode, I have persisted. The system uses the ASPX page as the user interface. In this step, design the corresponding page based on the features to be presented, call biz class to obtain the viewmodel, and bind it to the page. If we say M (BIZ class), V (ASPX page), and Vm (viewmodel), isn't this pattern like the legend?MvvmWhat about it?

 

The following is the system's user interface:

Member logon page

 

Customer shopping Homepage

 

Table-Driven Development Mode

This is my previous project and our company's existing project. There are also many companies working on the project development model. Let's talk about the development process of our company's latest project in detail:

I. analyze the requirements and create a static page as a demo

The requirement personnel keep the artist's production personnel, and create all static pages in modules and functions as system demos. This process is very long. The requirement personnel often modify the requirement repeatedly, and then ask the artist to modify the interface to indicate the system functions of the interface. These static pages are called demo pages.

2. Familiarize yourself with system functions on the demo page

Developers, demanders, and artists can view these demo pages. Developers ask questions and ask answers. If the developers question and make unreasonable suggestions, they can modify them. Of course, functional developers do not have the right to deny and modify the features. They only provide comments on the layout and display methods of the functions to facilitate program development and implementation. This process also takes a long time, usually page by page, and developers already have a division of labor in advance. Each person is responsible for a module and when they hear the module they are responsible, let's get up and listen. It's time consuming to meet modules unrelated to ourselves, that is, a flood of resources.

Iii. Table Design

This process is dominated by DBAs. The owner of each module works with DBAs to design the table and table fields related to this module based on the functions, forms, and form fields displayed on the demo page. This process also takes a long time, mainly focusing on the English names used to correspond to table fields, and the meaning and type of too many tables and table fields.

4. design the stored procedure on the Development page

According to the demo page in the early stage, developers use ASP. NET to implement it again. The main task is to write a lot of JS Code to dynamically call Background Data. DBA has all-inclusive data work. It compiles SQL functions for developers and outputs the data used on each page. For convenience of interconnection, the output data field names are in Chinese; the functions of the program, that is, the so-called business logic, are all written in the stored procedure by the DBA. DBAs concentrate on the storage process and use the coolest features on sqlserver 2008. Developers concentrate on aspx pages. The bll layer is just a sound transmitter, and the Dal layer has been created by PDF. the net code generator is automatically generated. You don't need to worry about it. You just need to ask how to write the SQL statement of the DBA function. DBA is happy and attentive, and developers are happy and easy (although it is physical.

V. Test

When developers develop of all modules and DBAs finish all the stored procedures, the testers are finally ready. After a test, there were a lot of bugs, mainly because the data was incorrect. The function implementation was different from the requirement, and everyone started to change the bug. It took us two months to develop the project, and it took more than four months to test and modify the bug. Some colleagues had to leave because of the repeated attacks by testers and demand personnel, everyone is hoping to end the project quickly.

 

After the project development is complete, someone asks if our system has any business model and most of them are uncertain. When they say "go to the Database", ask if the development skills have improved. The answer is that we are more familiar with Js, the rest will be gone; ask your development document again, and say "the development document has been useless for a long time". If you have any questions, go directly to the code.

One project and one project are developed in this way. Year after year, day after day, everyone's job is to write code, change bugs, and there is no change.

 

Differences between the two development modes

Next, let's look at the "Domain-driven development" model. What's different:

1. Domain-driven systems focus on the design of the "domain object model". They can be designed first, tested, and finally developed;
2. Domain-driven systems can generate core values-"domain object model ";
3. Domain-driven development makes it easier to focus on the key functions of the system throughout the development process, making it "targeted ";
4. Domain-driven systems do not need to focus on data issues, making cross-database migration easier;
5. Domain drivers focus more on "Business" than "data itself" and are suitable for scenarios with extremely complex business needs;
6. Domain drivers focus more on "Business Objects", so that they can use various design patterns and architecture models, making the system easier to expand and optimize.

We have a deep understanding of this point in our existing systems. Because all business logic is written into the storage process, the system running efficiency is low now. without changing the hardware, no space for optimization.

 

Of course, the table-driven development mode has nothing to do with concurrency. It is suitable:

1. The overall design capability of the development team is insufficient;
2. The business of the project is not very complex and the business functions are not changed frequently;
3. Data-centric, with core values in the project;
4. Strong DBA team

 

Generally, many project businesses are complex, not data-centric, and do not have a strong DBA team, but still choose "table-driven development mode ", I think the main reason should be that "the overall design capability of the development team is insufficient", while the "design quality" of projects or products directly affects the "cost" of projects or products ", or even "success or failure. "Design to cope with changes" depends on whether you agree.

 

In the original table-driven development model, we can only use the demo on the page to find out which tables and fields should be available. It is difficult to analyze complicated business objects and related business processes in the middle, each part of the program is severely "split!
The domain-driven development model analyzes the requirements, obtains the domain model, verifies the model with the business, and gradually improves the model. The second step is to implement the business scenario, obtain the attributes of objects in which fields need to be persistent, and obtain the attributes of which Combinations need to be displayed to the front-end (viewmodel). The third step is to design the view, use viewmodel to design the object class, finally, the user interface is developed.

As the beginning of this series, I would like to discuss with you the differences between the field-driven development model and the traditional table-driven development model. Here I am writing a bit of sentiment, because it is a theoretical nature, therefore, we will describe the "supermarket management system" instance in the next article.