Author: Anders James
Continued domain model: further design of Business Objects
Product Line
The product line system is quite special, and the concept of product line is not obvious. With product as the core, product line maintains the common attributes of a type of product and other related business objects such as document, and maintains information that is not suitable for maintenance at the product level: product and Other Business Objects and business logic, such as constraints with contract. The details are as follows:
Product Line maintains the common properties and associations of products.
1. Maintain the common properties of the product.
This is easy to understand. The most similar is the category object.
2. Maintain the association between products.
It is easy to understand that the purpose is only to maintain at one point to avoid unnecessary duplication.
The product line also maintains information and logic that are not suitable for maintenance at the product level (Note: it is not absolute. Generally, the following information and logic are maintained, in actual applications, it is targeted at the product line level, but in some businesses, it is also necessary to maintain specific products ):
1. Maintain the relationship between the product and the visitor object.
Product or contract always needs to be visible to the user. In Analysis Mode, 10.5.4 specifically discusses this content. Because the visitor of similar products has common characteristics, the relationship between the visitor and the product is not so direct. For some projects, the visibility of all products under the same product line is consistent, therefore, visitor is maintained at the product level.
In addition to the visibility of a single product, there is usually the product line search function. The types that support the search function are also maintained at this level.
2. Maintain the constraint relationship between the product and its associated objects.
This is a use case applicable to the definition of product. When the product relationship is complex, some constraints must be given to ensure the integrity of the product definition. For example, products have relationships with document objects, but document objects are classified into multiple types. However, for a product, three types of documents must be associated. Such constraints are defined on the product line object.
3. Maintain the constraints between product and contract.
In complex businesses, the relationship between contract and product is not one-way. In addition to contract which will maintain reference to product, the product also has a limited range of contract. For example, the settlement currency of the product; the actual example is: Ctrip's electronic air tickets only allow e-bank payment methods; some promotional items on eBay only allow express delivery agreement. Of course, for such constraints, the product level or product line level should be analyzed based on the characteristics of the project.
4. Maintain the constraints between product and business processes and behaviors.
This is rare, but it still exists. For example, for a product type, you are not allowed to make corrections in the business; for a product type, you must provide a business document in advance in the business process. In comparison, business processes (mainly page streams), business behaviors, and product line are usually associated, and rarely associated with a specific product.
Product Line is the most troublesome domain object system, including many logics. It is a bit confusing, but it is still reasonable to think about it.