Design capabilities-how do you do domain modeling

Artificial intelligence, zero-based entry! http://www.captainbed.net/inner  

Use four-color modeling method for domain analysis

There are many methods for domain modeling, and the models obtained by using different modeling methods for the same problem domain may be different. So I often hear the question: How can we ensure the correctness of modeling?

This sounds like a reasonable question, but in fact it is not so reasonable. First of all, we need to understand what is the purpose of modeling? If it is just to describe the problem, then there is no right or wrong—just the difference in position and perspective; and if it is to model the business system of the enterprise, then the question should become: how to ensure that the model can support the enterprise Operations?

I want to use the following example to briefly answer this question.

Before starting analysis and modeling, we need to know what the purpose of the enterprise business system is; and the purpose of the enterprise business system is often related to the demands of decision makers or management. We now need to empathize with a manager and see what his demands are.

Now imagine that you are the COO of an online e-bookstore. Suddenly one day, a customer complained to you that he ordered one less book and calculated the price wrong, so he paid more. Before you promise to settle the claim, you need to check whether what the customer said is true. So what kind of information do you need to know to make an accurate judgment at this time?

Simply put, you need to know which books the customer ordered, how much they paid, and what books the bookstore delivered to this customer. Unfortunately, due to underdeveloped technology, you can't directly drive the time machine back to the past to see for yourself what happened. Fortunately, you don't need to do this. You only need to look at the customer's order, online banking payment records and the courier slip stubs that your bookstore handed over to EMS, and you should know this information.

You found the order and EMS courier stub. It was found that this customer ordered the book three days ago, and you had already mailed the book the day before yesterday. And on the order, I saw that the customer had ordered 7 books in total, but on the EMS courier stub, there was no book information, only the address, package number, postage, and weight. At this time, you think you should ask the distribution department to see what they have done.

In the delivery department, you found the package information based on the package number. As expected, there are only 6 books in it. At the same time you found a backorder in the parcel department. The above stated that due to lack of stock, another book of this customer is waiting to be shipped.

Then the remaining problem is the payment problem. From the records of online banking, the customer paid a total of 132.5 excluding postage. The price shown on the order is also 132.5, and obviously this customer did not overpay.

In order to ensure accuracy, you re-selected these 7 books from the website and wanted to see if it would be the same price. But you find by accident that only 128.3 is needed in total. After careful identification, you find that a book is now on sale. The question now is, when did the promotion start?

You went to the marketing department, and the marketing department gave you a recent promotion plan. You find that the book was only on sale yesterday, that is to say, when the customer placed the order, the sale hadn't started yet.

At this time, you feel that you should give your customer a phone call to apologize, discuss how to post it, and explain to him the promotion.

Do you think this COO is a bit tired? This is of course fictitious. But what do we see from this story?

Any business event will leave a footprint in the form of some kind of data

Our tracing of events can be done by tracing data. As in the above story, you cannot go back to the past to see what happened, but you can restore the scene of what happened to a certain extent on the basis of documents. When we arrange the footprints of these data in chronological order, we can almost clearly infer what happened in the past period of time.

So why can the chain formed by these data help us trace the operation of our business?

Because these data are not randomly selected. If we review your process of checking this omission as the COO, you first chose the order and the EMS express stub. In other words, if there is an error in the order, or the EMS express stub shows that you did send 7 books, then this omission is The responsibility is not on you. So these two orders are actually the starting point and ending point of your corporate legal responsibility.

After you determine that the responsibility for this omission is with you, you choose to review the results of some process execution , such as package stubs. So as to verify whether the results of some major business process execution are correct. In other words, these data are the execution results of the key processes that support your operating system .

It is precisely because these data are the result of process execution that they enable us to trace and analyze certain emergencies without knowing the details of the process.

In addition to the extreme example (complaint) above, for any normal economic transaction, we all need to know:

  1. If I pay a sum of money, what are my rights?
  2. If I receive a fund, what are my obligations?

These questions require the business system to capture the corresponding footprints before they can be answered. Therefore, one of the main purposes of an enterprise's business system is to record these footprints and form an effective traceability chain.

As a business analyst, you should know that those events need to be traced back in operation, and what footprints these events leave behind.

These footprints usually have an interesting feature, that is, they are all time-scaled objects (moment-interval). Discovering these time-scaled objects is the starting point for modeling. After a little sorting of these time-scaled objects, we get the backbone of the entire domain model:

After getting the backbone, we need to enrich this model so that it can better describe business concepts. At this time, we need to add some physical objects. There are usually three types of physical objects: people, places, and things (party/place/thing).

On this basis, we can further abstract these entities if they participate in various processes. At this time, we need to use roles:

Finally, put some information that needs to be described into the description object (description).

We have a set of domain models built using color modeling.

A brief review of the above process, it is not difficult to find the order and focus of our modeling:

  1. First of all, to meet the needs of management and operation as the premise, find events that need to be traced.
  2. Trace back according to these needs, looking for footprints and corresponding time-scale objects.
  3. Find people/things/things around the time-scale object
  4. Abstract roles from it
  5. Fill some information with description objects.

Because in the first step, we use management and operation goals as the starting point for modeling. Therefore, the whole set of models is actually built around these "how to effectively track these goals". Such a model can ensure that the model supports the operation of the enterprise.

Four-color modeling

(Color UML) is a modeling method invented by Peter Coad, which divides abstracted objects into four archetypes:

  1. moment-interval: This kind of object represents those that exist at a certain point in time or will exist for a period of time. Such objects often represent an external request, such as an inquiry (Quotation), a purchase (Sale), and so on. Objects represent the value of the system, so they are also the most important type of objects, generally represented by pink. Such objects generally have a start time and end time, and a unique identification number, which is used to uniquely identify this customer request, such as PolicyNo.
  2. Role: This kind of object represents a role, which is often borne by people or things, and has corresponding responsibilities and rights. Generally, a moment-interval object will be associated with multiple Roles. For example, an inquiry (Quotation) involves Two Roles, Quoter and Product for Quotation, these objects are the most important type of objects except for the moment-interval object, which are generally represented by yellow. Such objects generally have some operations requested by the moment-interval object to fulfill their responsibilities.
  3. Party: Place or Thing, this kind of object often represents an objective thing, such as: people, organizations, products, accessories, etc., these things often play a role in a moment-interval, such as a certain Individuals can play the role of Customer in a purchase, and can also play the role of the inquirer in the inquiry. This type of object is the third most important, so it is generally represented in green. Such objects generally have attributes such as Name and Address.
  4. Description: This kind of object is generally a classification or descriptive object. Generally, a Thing, Place, and Party will belong to a Description, which is mainly used to represent a type of thing, and its attributes are generally available for this type of thing. Attributes, such objects are generally represented in blue. Such objects generally have attributes such as type and defaultValue.

to sum up

By categorizing the domain objects obtained by analysis into these four types of prototypes, we can have a deeper understanding of the responsibilities of each object and the relationship between the objects. Through the four colors, it can express more than the general black and white model. Rich field information.

Compared with other modeling methods, the four-color modeling method is more inclined to be an analysis method than a design method. It can also be regarded as an analysis mode, which is similar to Martin Fowler's "Analysis Mode" wonderful. In the book "Java Modeling in Color with UML", Peter Coad gave a common object model for many industries, including manufacturing, resource management, human resource management, financial management, etc., of course, they are all built in four colors. The modality is really refreshing

Guess you like

Origin blog.csdn.net/qq_35860138/article/details/109463264