Domain object: Analysis Based on Business Behavior

Domain object : Analysis Based on Business Behavior
-- Dynamic and Static domain object and its relationship with business process

Author: Anders James
Synchronized from: http://www.blogjava.net/AndersLin/archive/2006/08/25/65875.html

I. domain object
1.1 What are the static and dynamic standards?
During system operation, it is often set up and updated as "dynamic", and it is "static" to maintain stability for a long period of time ".

1.2 What is the significance of domain object?
Generally, the "dynamic" domain object group represents the core business objects of the system. Static domain objects represent system dependencies in terms of business.
Furthermore, we can find one or several representatives of the Core Business System in the "dynamic" domain object group. However, the core business objects are different from the integrated business objects. The most dynamic domain objects are not necessarily the core of the integrated business. The following is an example.
For example, in the insurance business, the objects involved are as follows:
Party (customer and various channel role), account, product, policy, etc,
Policy objects are most frequently operated, while party and product are relatively static.
The most common operations in actual business are about insurance policies: new contracts, preservation, claims, and renewal. Obviously, the policy object is the core business object; account changes will occur with the policy business, while party and product give the dependency relationship of the Policy object.
Then, the core of the comprehensive insurance business is party, which is more specifically customer. In fact, the core of almost all financial services should be the CRM system. Insurance Companies (financial institutions) provide comprehensive financial services to customers and help them manage financial assets, that is, holding, among them, the most important thing is the account. As for the policy, it is only an asset (asset) of the customer. Various organizations and channel role under the party all provide financial services to support the company.

In the springside demo, bookstore involves the following objects:
Party (customer, provider and deliverer), book, order, etc.
Order is the object of the strongest dynamic features, which represents the core business of bookstore. Similar to the insurance system, order and policy have the same concept. Book is equivalent to product, while deliverer is the channel role.
Similarly, the overall business of bookstore is also CRM. The system tracks and analyzes customers' reading habits, reading interests, and support habits to provide reading services for customers. Like Amazon.

Another example is the shipping example provided by DDD: itinerary is the core business object of shipping model.

2. domain object and Business Process
After clarifying the dynamic and static domain objects, we need to consider the association between domain objects and business process.
From the perspective of the actual system, the Business Proces of almost all systems (core business processes and integrated business processes) are associated with the status of the lifecycle of the "dynamic" core business object.

2.1 First, let's take a look at the core business process. :
Two phenomena of the core process are noted:
A. Almost all business operations start with the establishment of the core business object, and end with the death (STOP) of the core object. For example, the core business of insurance is implemented around the lifecycle of the policy, the new contract, preservation, claims, and warranty extension are all based on the policy; the bookstore is based on the order; at the same time, it is noted that different business operations will affect the status of the core object lifecycle.
B. Business process is triggered by a customer request (the customer applies for insurance from the insurance company, or requires warranty, an online customer buys a book order, or online payment; business Process triggers a series of business actions based on the lifecycle status and request context of the core object.

Now we will take the insurance business as an example to provide a complete description and observe the several concepts involved:
Party (customer, channel role), request, Business Action, business process, and final policy.
Let's take a look at the relationship below:
1. first, a request is initiated by the customer, in which the request is facilitated by an insurance customer representative, namely the agent (Channel role) (that is, the request object references an agent channel object)
This request will activate a business process: first, the basic information input of a policy is completed. This action directly leads to the creation of a policy object. At this time, the status of the lifecycle of this policy object is proposal;
3. the workflow system then enters the underwriting operation based on the lifecycle of the policy, and this operation prompts the policy to direct to the two lifecycle status: accept and deny.
4.1 For the accept policy, the system will trigger a notification to notify the customer to pay the first premium.
4.2 After the customer pays the fee, a system request is generated within the system. The request carries the payment information and enters the underwriting operation.
4.3 check whether the payment quota can be underwritten. If yes, the lifecycle status of the insurance policy changes to INFORCE.
5.1 for the deny policy, the system triggers a manual operation process. The staff will contact the customer to adjust the insurance information, such as reducing the insurance amount.
5.2 The customer reports a request. If the Customer agrees to reduce the warranty amount, the system enters an action to modify the policy, and the policy lifecycle enters the proposal state.
5.3 process for system entry 3

Here is a simplified description (In addition, the system does not necessarily use workflow). In actual business operations, the objects to be operated include other role in the Party, such as insurancer and payee, each policy also needs to specify the specific product, as well as the payment agreement, etc. When the core is undoubtedly the policy object, and the lifecycle status of the Policy object has a direct connection with the business process.

This is also true for bookstore.
1. The lifecycle status of order is proposal. During this period, the system waits for two requests from the customer: payment or order modification.
2. After the payment, the lifecycle status of the Order is INFORCE, and the system notifies the staff to start the assignment.
3. After the assignment is completed, the lifecycle status of the Order is assembled.
4. The system should notify the relevant personnel to send the order through deliverer. The lifecycle status of order during this period is deliver
5. When the system receives the delivery notification from the deliverer, it sets the lifecycle status of the Order to complete.

Here, we need to add additional instructions;
For a request, each request must record the date, but the channel is not necessarily.
For an action, each action may retain some manual intervention control information and be recorded together with the entry data of lifecycle.
For lifecycle, each change in lifecycle status may have its own entry data (related to the request context and domain) that needs to be recorded.

More than 2.2 of the discussions are about core business systems. Now we need to look at the so-called integrated business system. :
For a comprehensive business system, focus on the party and product object systems.
Obviously, the customer's financial assets (Insurance System) or reading habits (bookstore) are concerned by the system; the product is the service or product that the system can provide to the customer; provider and channel role, including deliverer, provide support for services.

These objects also have their own lifecycle. Although its lifecycle cycle may be longer than policy or order, its lifecycle status may be simpler than policy or order.

The party and product object systems also have their own processes, and the business process is initiated by the request. As compared with the Policy and order systems, the two systems are relatively "static ", in addition, due to its simplicity of lifecycle, these two types of objects have more formal authorization features than actual businesses. Therefore, I use a registry that is different from the request concept.

The process is almost the same as the core business process.
At present, there are no more ideas for integrated business systems.

Iii. Summary
Whether system modeling or System Reconstruction, efforts should be made to understand the dynamic and static domain objects and the relationship between domain objects and business process, which will help to analyze the business behavior of the system in a fine-grained manner, make reasonable design plans.
(It sounds more like a slogan)