Domain Analysis by Color Modeling

There are many methods for domain modeling, and different models may be produced for the same problem domain by applying different modeling approaches. So, I often hear such a question: How to ensure the correctness of the modeling process?

It sounds like a straightforward question, but in fact it could be more complicated than we might expect. Firstly, we need to make clear what is the purpose of modeling. If it is just for describing problems, then there is no right or wrong modeling, but only differences resulting fromvarious point of views and perspectives; however, if we are talking about modeling an enterprise business system, then, the question should be changed to: “How can we ensure the model is capable of supporting the operation of an enterprise?”

I would like to answer this question in brief with the following example.

Before carrying out analysis and modeling, we have to know what the purpose of an enterprise business system is. Generally, the purpose of enterprise business systems is relevant to the demands of decision makers or management. The next step is to empathize with a manager, and to find out what his or her demands are exactly.

Now, assume that you are a COO of an online eBook store. One day, a customer suddenly complains to you that one book he bought is missing, and the total price is miscalculated, that he overpaid some money. Before you make a commitment to settle the claim, you should firstly verify whether what the customer said is true. To do that, do you know what information is helpful for you to make an accurate judgment?

To put it simply, you need to know which books were ordered and how much money was paid by the customer, and which books were delivered actually by the bookstore. Unfortunately, due to the limitation of technology, you are unable to see what has happened. You don’t havedrive a time machine to drive and see. But fortunately, you don’t need to do so; instead, you can obtain the relevant information by checking the order form of the customer, the transaction record of your e-bank and the stub of express waybill delivered by your bookstore to the courier.

You check the order form and the stub of the courier waybill, and you find out that the customer ordered the books three days before, and your bookstore already sent out those books the day before yesterday. Besides, you also learn from the order form that the customer ordered seven books in total, but on the waybill there is only information about address, parcel number, postage and weight, without any information relevant to books. And now, you think you should ask the distribution department for more details.

From the distribution department you find out details about the parcel based on itsparcel number, and sure enough there are only six books. Besides, you find a delayed delivery order which indicates that due to stockout, one book bought by the customer is prepared to be delivered.

So, the remaining matter is payment. From the e-banking record, the customer paid a total amount of 132.5 excluding postage; the amount shown in the order form is also 132.5, which clearly indicating that the customer didn’t overpay.

To ensure the correctness, you re-select those seven books on the website to see whether the price is right or not. However, it is surprising that the total amount is only 128.3. After a careful verification, you find out that one of the books is now on sales promotion. And now, the problem is when did the sales promotion start?

The market department shows you a recent promotion plan, and you find that the book in question was on sales promotion from yesterday. That is to say, the customer placed the order before the sales promotion started.

And then, you might think you should make a phone call to your customer to apologize, to discuss book prices, and to explain the sales promotion.

Do you think this is too much for a COO? It is certainly a fictional example. But, what can we learn from it?

Any business event should leave traces in some form of data. Tracing events can be done by tracing the data. Just as it was described in the story above, you can’t go back to the past to see what on earth happened, but, by making use of the receipts, we can determine what happened to a certain extent. Then, when we chronologically order the data , we may infer what happened during a certain period of time.

Why can the chain of evidence formed by data help us trace a business operation?

That is because that data is not selected randomly. If we review the process of checking carried out by you as COO, we will find out that you firstly selected the order form and the waybill. If the customer made a mistake when placing the order, and the waybill shows that the company mailed seven books, then you are not liable for the careless omission. Therefore, the order form and the waybill are in fact the basis for legal liabilities of your enterprise.

After you confirmed that the liability lies with your company, you checked the execution results of some processes using the parcel form, verifying whether the execution results of major business processes are correct. In other words, that data is the execution result of key processes supporting your business system.

That data resulting from process execution helps us trace and analyze some urgent events without learning about process details.

Not only in the case of the extreme example (complaint) given above, but also in any normal economic transaction we need to be clear about the following questions:

1. If I paid a sum of money, what are my rights?
2. If I received a sum of money, what are my obligations?

Those questions can be answered only if corresponding traces are captured by the business system. Therefore, one of the main purposes of an enterprise business system is to record the traces and use them to form a valid traceable chain of evidence.

Now let’s shift our perspective back to a professional IT service provider. In order to build a traceable chain of evidence in an IT system, as a business analyst, you should know what events are required to be traced in operation, and what traces are left by those events.

Generally, those traces have a common interesting feature: they are moment-intervals. Finding out those moment-intervals is the first step of modeling. By slightly organizing the moment-intervals we will obtain the backbone of the whole domain model:

After determining the backbone, we need to enrich the model, enabling it to better describe our business concepts. At this time, we need to supplement the model with some entity objects. Entities are objects operating or being operated upon during moment-intervals, or places where moment-intervals happen. Therefore, there are three types of entity objects: party/place/thing.

On this basis, we can further explore how those entity objects are involved in different processes. To do this, role will be required, because in some cases one type of entity can play different roles in different processes. For example, in the following diagram, Employee entity can be either Distributor or Marketing Director in different scenarios:

And last, we can put more detaileddescriptive information about entities into the description objects. For example, in the domain model shown in the following diagram, the Book object might only contain a very limited and fundamental information about a book, such as title and ISBN, and other descriptive information of the book (author, summary, table of content, etc.) can be put in Book Description object.

So far, we have got a domain model applying the “object modeling in color” technique. Those colors were initially suggested by Peter Coad and others in their book “Java Modeling In Color With UML”: pink for moment-intervals, green for entities (party/place/thing), yellow for roles, and blue for descriptions.

By briefly reviewing the above processes, it is not hard to find the order and key points of the modeling technique:

1. Firstly, identify events needed to be traced based on the demands coming from management and operations.
2. Secondly, identify traces and corresponding moment-interval objects which can represent the events needed to be traced.
3. Then identify entities (party/place/thing) related to the moment-interval objects.
4. For entities which can play different roles (often party entities representing people), extract role object for each role.
5. At last, supplement entity information with description objects.

In the first step, we take the management and operations goals as the starting point of the modeling process. Therefore, the entire domain model is in fact established around the question “how to effectively trace those goals”. Such a model would be capable of supporting the business operations.

About the Author

Hao Xu, CTO and Principal Consultant of ThoughtWorks China, and member of ThoughtWorks Technology Advisory Board. He is also the founder of BJUG (Beijing Java User Group) and AgileChina.