Domain Model: further design of Business Objects

Author: Anders James
Synchronized from: http://www.blogjava.net/AndersLin/archive/2006/10/09/74187.html

In the dynamic and static domain object division, I have already divided the business objects into three categories, but I did not explicitly propose them in that section. The three categories are party, product, and contract.
Party
Includes party objects and role objects.
Party represents the entity of the Business occurrence object, and the role object is not only responsible for the corresponding responsibilities, but also one side of the party in the specific business, therefore, in addition to the responsibilities, there are also subsets that maintain some real business relationships. For example, a party has multiple addresses and accounts. One role uses only one address and one account.
There are two types of role. In terms of nature, it can be divided into individual and organization; in terms of business, it can be divided into customer, provider, and agency (and employee) in the middle ). Of course, further fine-grained modeling based on the business needs.
Not all systems require role. In some systems, the concepts of Party and role are not strongly differentiated. For example, in some common BBS or CMS systems, Party and role correspond one to one. Generally, only the role is designed and the party is ignored, or party the role object directly. But in other systems, they are different. For example, in an insurance system, it is common for a party to have multiple roles at the same time. In C2C systems such as eBay or Taobao, A Party can be either a buyer or a seller.
The relationship between role and role is a large logic. For example, an employee has a parent-subordinate relationship, and an agent has an Introducer. There are two ways to instantiate relationship: one is to create a role object, and the other is to use an independent relationship object.
Party is associated with another type of object holding, but the holding Object System is special. In the financial industry, holding is a key object system. In other industries, holding is not that important, but a simple account accounting function.

Product
The product object is troublesome and looks like another contract in the financial industry. However, in B2C or C2C e-commerce, products represent commodities in the real world.
There are two types of products: Main and rider. The main product can be sold separately, but the rider cannot. This is actually a solid package rule.
Another type of product, or package product, is a type of product that has the same attributes and behaviors as the product.
The product object domain consists of the product package rules and the product pricing logic.
The package rule of the product. For example, the rider product can only be sold as an accessory; some rider products can only be bound to a specific main product; some products cannot be sold at the same time with another product; some products can buy up to five copies at a time.
Product pricing logic includes two levels: internal and external. Internal is determined based on its own conditions, such as time and discount level; External is related to other products in contract. For example, if the total price of other products exceeds a certain price, additional discounts are obtained; or a product with more than three copies will have a certain discount.
Usually external is built on Internal. There are two types of relations: override and additional. Additional relationships are common, usually with additional discounts.
There are two methods to implement the billing logic: Rate Table and formula engine. For internal layers, Rate tables are common.
The two logics of the product object are more or less associated with contract. As described in the analysis mode, these two logics will be independent specification.

Contract
Contract is the key to the core business system. A business contract usually includes a series of sub-contract. At the same time, contract has multiple types. Like product, contract can be divided into main contract and rider contract. For example, payment agreement and deliver agreement are all rider contract.
Like product, the contract domain contains two Logics: the contract package rules and the billing logic.
Different types of contact include different sub-contract. For example, ILP and up in the insurance system contain different sub-contract.
Contract also has the pricing logic and is usually related to sale channels. For example, you can purchase a discount through the network. Its relationship with the product pricing logic is generally additional, and override is very rare.
Like product, the implementation of the pricing logic is also the Rate Table and formula engine. However, formula engine is common at the contract level.
A contract inevitably contains one or more products, but the product here is different from the above product called contract product, which is manifested: although the product has defined a large number of responsibility relationships (operation scopes), when these products are included in contract, they are usually parameterized (subtyped ), of course, there are also cases of parameterization, which can be considered as a special case.

Because contract is the key to the core business system, main contract associates a life cycle object. As mentioned above, the life cycle object will be the driving core of the system's core business processes. Another request object associated with contract.
In addition to the Contract Product, the status of all related parties in the event of business needs to be recorded for business re-query and Data Mining in the future, that is, the so-called historical data. Note that the data is not redundant.
 
BTW: considering that financial products are virtual in the financial market, they are a contract and contain a series of operation scopes-responsibilities. Note that in this case, a product contains a series of operation scopes-responsibility. From an external perspective, it also presents a complete concept. This is similar to the role structure. Although contract and product are naturally regarded as include relationships, because product itself is a complete concept, we can look at it in turn, product modifies contract. A policy contains different parties, and the insurance product in the Policy modifies the policy-describes the responsibility relationship between different parties.