Separation of data and events
Starting with Peter's data and events separately, Peter looked for Li Fuhua to discuss the need to achieve the return, his proposal is to separate the inventory and return relationship, that is, data and events separated: Do not let (event) state pollution data, for normal storage, allocation of storage This is the original ecological state (Native Status) is not a problem, for the return of this acquired event caused by the state should not be used to pollute the data, but a separate page hosting operations, a separate table structure to store the state; I think so; if so, should the library be separated? I do not feel the need to separate the inventory table just to keep the inventory information, indicating how much inventory is still in the "Native Status".
Demand kick
What are the core objects, what are the core object fields (provided by the customer, also consider the associated fields), what are the relationships between the business objects (how the two-tuple relationship is 1:1 or 1:*, what is associated with it), what is the relationship to the object outside the business, and what are the "constraints" of the business process? The purpose of the business and the subsequent impact of the resulting object (how the resulting data will be used);
What is a business model
Du Dong in the weekly meeting above put forward for the storage information, allocation, normal storage is in fact tied; but we are now putting the content together, have not been differentiated, such as batch number, for the allocation and the normal storage is actually allowed to repeat; but I think the business model is gradually aware that the classification process , of course, in the database physical storage can be placed in a table, but in understanding and planning, there must be a clear concept of each individual theme;
The business consists of two parts: data and process. The result of the business is the data (core data), the business process is independent, such as warehousing contains the transfer of business and normal warehousing business, issuing control of the out of the library and the allocation of the outbound, although they are warehousing/outbound (in the physical storage structure is consistent), but they do tie, parallel to each other, This is the physical storage of the performance is through a field to differentiate, the business layer (application layer) processing on the separate, to maintain the purity of each other.
This means that, back to the previous consideration, for any function point to be "ancestral to the Pope ", be sure to find a large class of attribution (if it does not, then create a new one), and then look for parallel classes under the large class, so that logically (the model) to do the separation, In the code implementation and database design are independent of each other, to achieve a better "clean" relationship, is so-called "gentleman cliquing."
So, it comes out that the nature of the business model is actually the "process" part of the business, which is to classify the process into a large class, separate the independent process unit (Dependency process Unit,dpu), and design the life cycle for each independent DPU, which is the establishment of the business model.
?
?
Business model of demand analysis