Domain Model Series: overview

A domain model is a visual representation of a conceptual class or object in the real world. Also called concept model, domain object model, analysis object model. It focuses on analyzing the problem area itself, exploring important business domain concepts, and building relationships between business domain concepts.

Concept

The business object model (also called domain model domain models) is an object model that describes the implementation of a business use case. It is an abstraction of how business roles and business entities should be contacted and collaborated to perform business. The business object model defines business use cases from the perspective of the business role. The model determines the static and dynamic relationships that business people and the objects they handle and use ("Business classes and objects") should have in order to produce the desired effect. It focuses on the role of the business and its current responsibilities. The objects of these model classes are grouped together to perform all the business use cases. The core element Business Role shows a range of responsibilities that a person undertakes. A business entity represents a deliverable artifact, resource, and event that is used or produced. The business use case implementation shows how a collaborative business role and business entity can perform a workflow. Use the following diagrams to document business use case implementations: The figure shows the participating business roles and business entities. Activity diagram where the swim lane shows the responsibilities of the business role, and the object flow shows how to use the business entity in the workflow. 　　A sequence diagram describes the details of interactions between business roles and business actors, and shows how to access business entities during business use case execution. 　　The business object model combines the concept of structure with the concept of behavior. It is a link artifact that is used to articulate a business relationship in a way that is similar to how software developers think, while retaining some pure business content. 　　The information we know about the business is merged with objects, attributes, and responsibilities. 　　It explores the nature of business domain knowledge and the way in which we can shift from thinking about business issues to thinking about software applications. 　　It is a method of determining requirements that enables requirements to be used by the pending information systems and is supported by the system.    The process of determining business object definitions, relationships between objects, object names, and relationship names between objects enables us to express business domain knowledge in an exact manner that can be understood and validated by the business domain experts.

domain model namingnaming each business role and entity requires the name to represent the responsibility of the object. A good name is usually the noun form of a noun or verb, and each name must be unique. Avoid using words like pronunciation or spelling and synonyms as names, and you may need to use several words to form a clear, unnecessary name. ObjectWhen you study business roles and business entities that participate in different use cases in your business, you may find that some objects are so similar that they are actually a class. Even if different business use cases do not have the same requirements, the class is likely to be similar enough to be considered a similar phenomenon. If this is the case, you should merge similar classes together. 　　This creates a business role or business entity that has relationships, attributes, and operations that are sufficient to meet the requirements of different business use cases. As a result, multiple business use cases can have different requirements for the same class. For business roles, if some employees are able to perform a set of roles described, there are also employees who are more flexible and capable of multiple positions. This will make your business more flexible. ModelIn the business object model, the business role represents the role that an employee will play, and the business entity represents the object that the employee will handle. On the one hand, you can use the business object model to determine how business employees will interact to produce the results that business leads expect. 　　 On the other hand, the system use case model and design model specify the business information system. Business modeling and system modeling solve different problems, and their levels of abstraction are not the same. 　　So in general, information systems should not appear directly in the business model. On the other hand, employees use information systems as business roles to communicate with each other, communicate with protagonists, and access business entity information. 　　All links, associated relationships, or attributes are supported by a potential information system. The two types of modeling environments have the following relationships: employees as a particular business role correspond to a system lead in an information system. If an information system is established so that the employee is supported by a system use case for all of the work in the business use case, he is most likely to get the best support. In addition, information system use cases can support the operations of business roles if the business use cases are large, long-lived, or combined with work in several separate areas. The objects that employees work with (modeled as business entities) are often represented in information systems. In the object model of information systems, these business entities appear as entity classes. The association and aggregation relationships between business entities often result in corresponding relationship and aggregation relationships between entity classes in the design model. Therefore, system use cases access and manipulate the entity classes in the design model, which represent the business entities that are accessed by the supported business use cases. Finally, the business lead that uses the business information system directly also becomes the system protagonist of the information system. These relationships are critical when determining the need for information systems that support the business. protagonists Sometimes, a business employee is contacted by an employee of another business using an information system of other businesses. 　　From the perspective of business after modeling, this information system is a business protagonist. Example: A software developer tries to understand the problems that arise in the product that he is responsible for. To see if the problem originated from the programming tool he was using, he contacted the vendor's World Wide Web server and carefully examined the list of known issues in the current version of the programming tool. In this way, the business role software developer interacts with the business role provider's World Wide Web server. positioningIt is common practice not to explicitly model information systems in the business object model, because information systems are only tools used by business roles. But when the business information system is used directly by customers, this approach is not appropriate. If this interaction is a major part of the business service, you may want to show it in the business object model for business importance. 　　The telephone banking business is a good example of such information systems. From a business modeling standpoint, it is recommended to use the following approach: To see an information system as a fully automated business role that interacts with the protagonists. If the information system is related to any other business role or business entity, consider using a link or association relationship to illustrate the relationship. The system may notify a business role of its progress, or use information related to a business entity. Simply describe the business role and list services that represent information systems in the business object model. In the information system model, all the details and characteristics of the information system and its environment are modeled. Introduces a naming convention that makes it easy to identify fully automated business roles in business roles, such as a prefix or suffix, such as "Auto < business role name >" or "< business role name > (IT system)." You can even use a special icon to define stereotypes. characteristicIn general , business roles and business entities perform all the activities described in the business use case, no more, no less. The business object model shows the organization effectively and comprehensively. Designgive a simple example to illustrate how to design a domain model. If we want to design a invoicing system for a small shop, she provides us with the business description is such: Every morning from the Bouginon batch market to buy apples, pears, grapes, oranges, bananas, litchi, walnuts and so on, anyway, what good sell her to buy back to sell. 　　Grapes, Litchi can not be retained for a long time, generally to sell the day .... For the above business description, how do we conduct domain model design. 　　I have given the following steps to complete the domain model design. To sum up the nouns in the business description, first build a noun list, and list the related nouns: ordinal noun remark; 1. Bouginon Batch Market 2. The person who buys the thing is an implied noun, every morning from the farm market to take goods 3. Apple 4. Pear 5. Grape 6. Orange 7. Banana 8. Litchi 9. Walnut 10. The customer is an implied noun, bought back to sell the object 11. The noun, which is irrelevant to the entity and the role, has a list of the behavioral subjects: roles, and operational entities in the business process: the model, which is helpful for our next use case description, domain model analysis, and requirement analysis. Of course, this list of nouns needs further analysis and refinement, and becomes a domain model to determine the business entity ordinal noun description; 1. The Bouginon market is not an entity of this business 2. The person who buys is a role in this business 3. Apple is an entity 4. The pear is an entity 5. Grapes are an entity 6. An Orange is an entity of 7. Bananas are an entity 8. Litchi is an entity 9. Walnut is an entity 10. Customer is a role in this business 11. The nouns of the morning and the day are not related to the entity or roleAbstract business modelafter analysis, we come to the entity are apples, pears, grapes, oranges, bananas, litchi, walnuts, these are not models it. It should be said that it is not, but also after further analysis: In our analysis of the business areas, they have no commonality. Apples, pears, grapes, oranges, bananas, litchi belong to fruit, walnut belongs to dried fruits, they are a specific example of fruit. And in fruit grapes and litchi belong to the unfavorable preservation of fruit, through this further analysis to draw the following field model legend: Fruit Invoicing domain model not only reflects the current operating entity, but also to our needs analysis personnel and system functions to provide a certain expansion of vision: future will not operate food, Short-term to keep fruit to take what profit space to promote, long-term preservation of fruit will not be saved because of the cost of the loss of profits.

Relationship　　

It is considered that the domain model is an analytic model, which helps the system analyst and the user to understand the real business tools, describe the entities involved in the business and their relationships with each other, and it is the product of the requirement analysis, which is related to the problem domain. The domain model is a powerful tool for the communication between the demand analyst and the user, the concept that the demand analyst and the user understand together, and the language that communicates with each other. The data model is a part of system design and implementation, which describes the implementation of user requirements in data structure. 　　Of course, the conceptual model design in the data model is similar to the domain model and lacks the broader relationship description between entities. 　　Usually you will consider how the data is stored, and my understanding is that the domain model design does not take into account the storage of data, only the entities involved in the business description and the relationship between the entities. The relationship between the entities, a lot of books are said, is nothing more than generalization, dependence and association, the Association has been divided into General association, aggregation, combination and so on, I am not listed here. summarizing domain model design is the key step of requirement analysis. 　　It helps users and demand analysts establish business concepts, determine the problem domain of the user's business, the scope of the system involved, and so on. The steps for domain model design are: 1. Extract the noun from the business description; 2. Summarizing the business entity from the extracted noun, distinguishing the attribute, role, entity and instance in the noun, forming the set of operation entities in the problem domain; 3. Abstract the business model from the business entity collection to establish the concept of the problem domain (for example, in the previous example, we call perishable fruit "short-term Keep fruit", of course, can be other statements, as long as the user can reach a consensus); 4. The methods and illustrations provided by UML are used to design the domain model and to determine the relationship between the models.