What Is a Domain Model?

The domain model is a visual representation of conceptual classes in the domain or objects in the real world. Also called conceptual model, domain object model, analysis object model. It focuses on analyzing the problem domain itself, discovering important business domain concepts, and establishing relationships between business domain concepts.

A business object model (also called a domain model) is an object model that describes the implementation of business use cases. It is an abstraction of how business roles and business entities should be connected and collaborated to perform business. The business object model defines the business from the perspective of the business role

A business role shows a range of responsibilities that a person assumes. Business entities represent deliverable artifacts, resources, and events that are used or produced. business

Name each business role and entity, requiring 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 that are similar in pronunciation or spelling, as well as synonyms, and use several words to form a clear, unambiguous name.

When you study different engagements in the business

In the business object model, business roles represent the roles that employees will play, and business entities represent the objects that employees will handle. On the one hand, a business object model can be used to determine how business employees will interact to produce the results expected by the business actor. On the other hand, the system use case model and design model specify the information system for the business.

Sometimes employees in one business communicate with employees in another business using information systems in other businesses. From a business perspective after modeling, this information system is a business protagonist.

Example: A software developer struggles to understand a problem in a product he is responsible for. To find out if the problem originated with the programming tool he was using, he contacted the vendor's Web server and carefully studied the list of known problems in the current version of the programming tool. In this way, the business role "software developer" interacts with the business role "provider's web server".

It is common practice not to explicitly model information systems in the business object model, because information systems are just tools used by business actors. But when the business information system is used directly by the customer, this approach is not appropriate. If this interaction is a major part of a business service, you might want to expose it in the business object model for business reasons. Telephone banking is a good example of such an information system.

From a business modeling perspective, the following approaches are recommended:

Think of an information system as a fully automated business role that interacts with the protagonist. If the information system is related to any other business role or business entity, consider using links or relationships to illustrate the relationship. The system may notify a business role of its progress or use information related to a business entity. Briefly explain the business roles and list the services that represent the information system in the business object model. Model all details and features of the information system and its environment in an information system model. Introduce a naming convention that makes it easy to identify those business roles that are fully automated in a business role, for example, a prefix or suffix such as "Automatic <business role name>" or "<business role name> (IT system)". You can even use a special icon to define stereotypes ^[3]

Overall, business roles and business entities perform business

Take a simple example to illustrate how to design a domain model.

Suppose we want to design a set for a small store

Think of the domain model as an analysis model, a tool that helps system analysts and users to understand the actual business. It describes the entities involved in the business and their relationships with each other. It is the product of requirements analysis and is related to the problem domain. The domain model is a powerful tool for demand analysts to communicate with users, a concept understood by demand analysts and users, and a language for communicating with each other. The data model is part of the system design and implementation. It describes the implementation of user requirements in the data structure, and that's it. Of course, the conceptual model design in the data model is similar to the domain model. What is lacking is a broader description of the relationships between entities.

Generally, people will consider how to store data. My understanding is that during the design of the domain model, there is no need to consider the storage of data. Only the entities involved in the business description and the relationships between the entities are considered.

The relationship between entities is described in many books. It is nothing more than generalization, dependencies, and associations. Associations are divided into general associations, aggregations, combinations, and so on. I won't list them here.

Domain model design is a needs analysis

Domain model blood loss model

In simple terms, the domain object only has getter / setter methods for properties, without any business logic.

Domain model anemia model

In simple terms, domain ojbect contains domain logic that does not depend on persistence, and those domain logic that depend on persistence are separated into the Service layer. Service (business logic, transaction encapsulation)-> DAO ---> domain object
Advantages of this model:
1. Each layer has a one-way dependency, a clear structure, and is easy to implement and maintain. 2. The design is simple and easy. The underlying model is very stable. The disadvantages of this model are:
1. The persistent domain logic of the domain object, which is more closely dependent, is separated into the Service layer, which is not enough.
2.The service layer is too heavy

Domain model congestion model

The congestion model is similar to the second model, the difference is how to divide the business logic, that is, the majority of business logic should be placed in the domain object (including the persistence logic), and the Service layer should be a very thin layer It only encapsulates transactions and a small amount of logic, and does not deal with the DAO layer.
Service (transaction package) ---> domain object <---> DAO
Advantages of this model:
1. It is more in line with the principles of OO 2. The service layer is very thin, it only plays the role of Facade, and does not deal with DAO.
Disadvantages of this model:
1. DAO and domain object form a two-way dependency. Complex two-way dependency will cause many potential problems.
2. How to divide the logic of the service layer and the logic of the domain layer is very vague. In actual projects, due to the difference in the level of design and development personnel, the entire structure may be chaotic.
3. Considering the transaction encapsulation characteristics of the Service layer, the Service layer must provide corresponding transaction encapsulation methods for all domain object logic. As a result, the Service completely redefines all domain logic, which is very cumbersome, and the transaction encapsulation of the Service The significance is equivalent to the Service TransactionScript of OO's domain logic. The congestion model, which is implemented arduously in the domain layer, becomes procedural in the service layer. From the perspective of the web layer programmer, it is no different from the anemia model ^[5] .

Domain model

Based on the third shortcoming of the congestion model, some students proposed that they simply cancel the Service layer, leaving only two layers, the domain object and the DAO, to encapsulate transactions on the domain logic of the domain object.
domain object (transaction encapsulation, business logic) <---> DAO
It seems that ruby on rails is such a model, he even merged domain object and DAO.
Advantages of this model:
1. Simplified layering 2. Also considered OO
Disadvantages of this model:
1. Many service logics that are not domain logic are also forced into the domain object, causing the instability of the domain ojbect model. 2. The domain object exposes too much information to the web layer, which may cause unexpected side effects.
Among these four models, the blood loss model and the blood swelling model should not be promoted. Both the anemia model and the congestion model are technically feasible. But I personally still advocate the use of anemia models. The reason:
1. Refer to the third shortcoming of the congestion model. Because the exposure to the web layer program is still the Service Transaction Script, for the web layer programmer, the meaning of the underlying OO is lost.
2. Refer to the third shortcoming of the congestion model. For transaction encapsulation, the Service layer must provide a procedural encapsulation for each domain logic. This is redundant for programming, which is very cumbersome.
3. The two-way dependency of domain object and DAO In a large project, it is easy to introduce unpredictable potential bugs, considering the differences in the level of team members.
4. The criteria for dividing domain logic and service logic are uncertain, often based on personal experience. Some people feel that a certain business is closer to the domain, and some people think that the business is closer to the service. Due to the uncertainty of the division criteria, the consequence is that many such disputes and disputes will occur in the actual project. Different people will have different division methods, which will eventually cause the entire project to be logically layered and confused. This is not like the classification in the anemia model that I proposed based on whether to rely on persistence. This standard is very deterministic and will not cause controversy. Therefore, this kind of problem does not occur during team development.
5. The domain object of the anemia model is indeed not rich enough, but we are doing projects, not research, and it is easy to use, whether it is so pure OO? In fact, I don't agree with the argument that firebody believes that the anemia model has a great stride in the design model and implementation code. When a design model is implemented, you get two classes directly: an entity class and a control class. There is no span.