Analysis Mode-responsibility Mode

The conceptual model is hard to tell clearly. An overview is as follows:
The most intuitive example is the organizational structure. The relationship between the upper-level organizational unit and the lower-level organizational unit is a specific link. Martin abstracts it into a responsibility relationship. The relationship between people and organizations is the responsibility relationship, the relationship between managers and deployment is the responsibility relationship, and the relationship between departments and department heads and managers is the responsibility relationship. In the book, Martin further generalized this relationship to a wider range. I personally think there is not much practical value, because the business concepts in specific applications cannot be too generalized. Otherwise, it will be very far-fetched, that is, some parts and interfaces in the software structure are overly liable. Note that at the beginning, all concepts in the model are interface-oriented rather than implementation-oriented, therefore, the object type and the derived type do not necessarily have an inheritance relationship, and different derived types do not have to be in the same database table, but only implement an interface.
There are some abstract concepts at the abstract level.
Party: participants. Any Party in the responsible relationship belongs to the participants.
Accountability: responsible relationship. It can be understood from the data model as the correspondence between two or more participants and related attributes.
Commissioner: The entrusting party. In specific examples, it is the owner and Administrator of the participants.
Responsible: Responsible party. In specific examples, it refers to lower-level organizations and managers of participants.

In the original book, Martin uses the object model, especially the non-standard class UML representation (Odell notation, that is, the method used by ERStudio), so it is difficult to understand. The other reason is that the abstract level is relatively high, there are many design variables in the specific environment, the gap between the object model and the data model may be large, and the responsibility relationship between objects is a bit cumbersome, this is one of the reasons for hard understanding.
In many large data processing systems, this design is very flexible and looks intuitive. There is no conceptual interference, and the object model is unpredictable. Therefore, we mainly take a note using the data model method.

Pattern 1:
The most common design is to use a simple Adjacency List Model, such as the design of the organizational structure.
Data Model: Object Model:

In the anemia model, int ParentId can be used to associate the upper-level organization. You can move forward with Organization1 Parent, or use an IList <Organization1> Children

For small organizations and companies, this design can basically meet the requirements. The situation is slightly more complex. For example, large manufacturing enterprises have factory production organization structure, distribution channel organization structure, and Group headquarters administration organization structure, in a matrix organization, different organizational structures form a matrix crossover, such as a product line or project, and cross functional organizational structures. This requires a high design of organizational structures.

Pattern 2:
Based on the above example, consider a slightly more complex situation. For example, there are two organizational structures that need to be managed, one is the sales organizational structure, and the other is the production organizational structure. A simple design can be like this.
Data Model: Object Model:

This is to store the two trees together. Each organizational structure may only belong to the sales organizational structure, production organizational structure, or both of them, and maintain and use each tree, similar to pattern 1

Pattern 3:
1. if there are more organizational structures, it is difficult to maintain pattern 2. From the graph theory point of view, both pattern 1 and pattern 2 use node) it is stored together with the edge (parent-child relationship) of the tree. The two data are stored separately, which provides the foundation for further expansion. Separated storage of organization objects (nodes) and Organization tree (edge)
2. Consider the following organizational structure relationship:

The headquarters of the Group can only be the regional headquarters, and the regional headquarters can only be a branch. When an organization (node) is used to construct a tree structure, certain rules must be followed. Therefore, the organization (node) the types are extracted independently, and rules are created on the types. The purpose is to easily add a new organization (node) type. You can create a new organizational structure without modifying the code by using rule configuration.
3. different organizational structures also use different types (Organization types and organization structure types are two concepts, the former is the node type and the latter is the tree structure type). Each type corresponds to a tree structure, to add a new organizational structure, you only need to add a new organizational structure type and configure it.

Data Model:

Organization3Type: organization type, such as regional headquarters, branches, and sales points
Organization3StructureType: Type of the organizational structure, such as the sales organization and production organization.
Organization3: Organization (node) object
Organization3Structure: Tree Structure
Organization3StructureRule: a rule table, for example, a tree structure rule composed of an organization (node) object.

Data example:


Note:
1. the design scheme of the object model is flexible and will not be listed, so as to avoid misunderstanding of the damn UML.
2.
Organization3StructureRule is only responsible for limiting Organization3Structure, which describes and limits the approximate shape of the tree structure. To modify the rule data in the rule table, make sure that the existing data in Organization3Structure complies with the new rule.
It can be understood that the business objects are Organization3 and Organization3Structure. Other data and objects are only some design structures, so as to facilitate business expansion. Martin summarized it as a knowlege level and an operational level, which is not personally recognized because it is not necessary to create these concepts.
3. add a new organizational type, a new organizational structure type, configure the organizational structure tree composition rules, and then you can maintain different types of organizational structures. From the perspective of Organizational Structure Maintenance, this is a configurable design.
This data model design scheme has high flexibility for specific business fields. Therefore, the object model is not necessary to be too complex or highly abstract. The problems caused by the complexity of the Code may not be worth the candle. It is sufficient to encapsulate the object model to make the organizational structure design more convenient.
Refer to SAP system. The organizational structure is just a basic data. Their complexity lies not in data maintenance, but in the use of other business modules. To achieve flexible business design, the flexibility of basic data is only one aspect. How can we make the logical processing rules of the business system configurable when using the basic data, is a deep topic. Similarly, if this goal is achieved, there is no need to abstract the object model too much, and one-to-one correspondence with the data model is enough, this is why large systems such as SAP and Oracle do not see too many object-oriented traces.
From this point of view, Martin's attempt to use object models to describe these complex business conceptual models is a wrong choice and misleading.
4. This data model is just a simple example and can be changed flexibly in practice.
For example, in a large production enterprise, it is unlikely that all Organization (node) objects are saved in one table. For example, companies, factories, and workshops are usually the main types of production organization structures, they may all have some basic attributes, but they all have their own special attributes. Naturally, the following design method will appear:

All attributes are stored in the "basic organization structure data table", and their special attributes are stored in the company, factory, and other tables respectively. One-to-one association is used.
The same rule is not limited to this form in the example. Different rules can be saved in different tables as shown above.
Similarly, no matter how the table structure is designed, the object structure is not necessarily an inheritance or other relationship, and can be combined, aggregated, and associated.
If the business module is highly configurable for the use of these basic data, there are usually many such design methods.

Abstract responsibility model
As a mode, it cannot be limited to the organizational structure, so the abstract concept includes the participant Party, the Accountability relationship Accountability, the delegate Commissioner, and the Responsible Party Responsible. For example, the object model of the participant Party may be similar:

The Parent_Org_Id and Child_Org_Id in the preceding pattern 3 Organizational Structure example correspond to Commissioner and Responsible respectively.
In a specific business design, there is no need to use an interface that is too broad, so you can abstract it in a specific problem area.
There is a general relationship between Organization, Person and Party, but not necessarily the inheritance of interfaces. The form may be similar to Organization3Type in pattern 3, that is, generalization through configurable types, this is the Party Type Generalizations mentioned in the book.

Operating Scope operation range, Time Period valid Time
For example, the effective time period in the BOM structure is required. For operating scope, the example mentioned in the book is also necessary in that case.