Those things of the domain model: acquiring knowledge from the field

Did you write a use-case model? Have you ever written a domain model? Maybe not yet. Here we can try to write a domain model and see what it does and what benefits it brings.

As RUP spreads in China, people begin to try to guide the design and development of software using the RUP Unified process, but these attempts are not successful. More generally, everyone started using use case models to analyze and design the requirements phase. Of course, it's great to make the first move, but it's far from enough. To do the requirements analysis, the use-case model can help us to analyze the various processes required in the software requirements, but we still lack oo analysis. In the past, once the requirements analysis was completed, a brief analysis process began to enter the development phase immediately. In the development phase, what classes should be designed, what their responsibilities are, what attributes and methods should be designed for them, how to work together, when and who to create, the above issues are not systematically analyzed, but are very casually added to the class, and very casually add properties and methods, And it's very casual to create objects at some point. Such a design, although can realize the requirements required by the function, but it must not be low coupling, cohesion well-structured classes poly, to achieve a flexible, highly maintainable system. Even with the flash of a few experienced programmers, that can only be optimized in one area, and is still not an ideal design for analysis as a whole. In short, without systematic oo analysis and design, we can't improve our code quality. To do the OO analysis and design of the system, it is necessary to start from the domain model in the requirement analysis phase.

In a strictly speaking sense, the domain model is not really OO analysis and design. The real OO analysis and design is the analysis and design (i.e. analysis model and design model) that are completed by the technician after the requirement analyst completes the requirements analysis. But the domain model is preparing the material for future analysis and design. The use case model prepares the material for the process operation (dynamic model) for future analysis and design, while the domain model prepares the material (static model) of the relationship between classes and classes for future analysis and design. A domain model is a description of all things that may be cared for in the future (which may be described as classes or attributes in a class) and the relationships between them. Therefore, the domain model is a batch of class diagrams, along with their descriptions. It is written together with the use case model in the requirements analysis phase, in no order, and is submitted as work results after the completion of this phase.

As with the use case model, the establishment of domain models is gradually advancing in an iterative way. But there have been fewer books describing domain model design, even in the classic UML and model application of Master Craig Larman, which is also vague about the domain model. However, this situation was broken by another master, Eric Evans, and in his classic field-driven design, we described in detail how to drive us through the domain model for OO analysis and design. Let's start our field-driven journey.

Extracting knowledge from the business domain

In a sunny afternoon, we suit each other, energetic to come to the client's office site. In a bright meeting room, a large, dark brown oval wooden table has gathered more than 10 business people. When we came in, everyone shook hands and greeted. After being seated, introduce each other, Exchange greetings, Lao Lao homely. A common home, or a person who is not well acquainted or familiar, may be the reason for closer relationships. Gradually, everything began to come to the point. Customers start to ramble about their needs, and we're in a tight record, asking questions, showing our position, and expressing our suggestions. In such a process, the customer will describe each of their business, will explain the process of each business, they will speak a number of business areas of the professional vocabulary (although some you did not understand). In such a process, as a requirement analyst, you should pay close attention to some key terms in the business process, and you should (or later) extract them, by asking the customer, figuring out their definition, and the relationship. And these words are the beginning of building a domain model.

This is a business seminar for financial software, and a business person is telling me how the payment form is made into a voucher. "Each payment slip has a detailed list of items, each of which has its price, quantity and amount." "He pointed to a single payment one-way I explained. From this sentence, I can put forward some key information: payment slip, commodity detail, price, quantity and amount. The payment slip is a one-to-many relationship with the product details, and the product details are aggregated in the payment form. Each product detail has the price, the quantity and the amount, namely, the price, the quantity and the amount is the commodity detail attribute, this all is very clear. Next, his explanations are not so clear and easy. "If a voucher is generated according to a document, a voucher is generated for each payment form," the paper said. Each detail in a document generates a debit entry and a credit entry in the voucher. As a debit account for the payment account in the payment slip, the settlement method account that corresponds to the payment slip settlement is treated as a credit account. The existing payment form has been made in the purchase invoice, so the voucher is no longer produced separately. Non-prepaid payment orders do not produce vouchers, but the implementation of their payment after the write-off, the production of vouchers in the verification sheet. "After the analysis of the above language, we can draw the following relationship: A voucher contains multiple ledger transactions, is the cohesive relationship." The ledger transactions are divided into debit entries and credit entries. A line of merchandise corresponds to a debit entry and a credit entry. The debit entry contains the debit account attribute, which corresponds to the payment account in the payment slip, and the credit account attribute in the credit entry that corresponds to one of the accounts in the payment slip. Here, you may not understand the client's description, so ask him for an explanation. The original customer has developed a rule, the payment form in the settlement method distribution corresponds to a settlement method subject. OK, you are drawing the graph, the settlement method account as the association class, the settlement method and credit account have an association. In this way, the domain model for a scenario such as "Payment receipt generation Voucher" is plotted (see chart).