Those things of the domain model: pay attention to what

Before we talked about how to get knowledge from the business domain and create a domain model, what should be paid attention to when building a domain model?

Problems to be paid attention to in establishing domain model

1. The domain model is not a data model, nor is it a software object model

One of the easiest mistakes in creating a domain model is to take the domain model as a data model or a software object model. The domain model, also called the conceptual model, the domain object model, or the Analysis object model, is "dedicated to interpreting the important things and products" [RUP] in the business domain. Domain models focus on objects in the real world (conceptual classes) rather than in the software world. It does not contain any database elements, software classes, system architectures, and responsible software objects. The future analysis model, design model and data model will take the domain model as a reference, but it is likely to differ greatly from the domain model. So when building a domain model, don't confuse it with these models.

In the past times of C/s, demand analysis often drew a data model. The data model, which we often call the E-R model (entity-relational model), is an analytic model based on relational database, which contains a lot of database elements, such as primary key, foreign key, data dependency and so on. The domain model is not a data model, and it should not contain these content.

The domain model and the Software object model are the same class diagrams, which cause the domain model to be confused with this kind of model often. The domain model is a reflection of the objects in the real world, so the domain model should not contain software elements such as factory class, window interface, software architecture, and domain model is not equivalent to the analysis model and design model used in the design and development.

Conceptual classes in a domain model usually have only the main attributes associated with them, and there are no methods or functions (sometimes conceptual class-even attributes can be omitted to describe only the relationships between them).

2. The domain model is not a picture, but a series of graphs

As I mentioned earlier, a complex and messy class diagram is often confusing, and so is the domain model. The domain model should be divided into one scene after another, each scene a graph, carry on the domain analysis. Depending on the actual needs, the scene can be large or small. If a module involves a small number of concepts and a clear relationship, we can use a larger scenario to describe, and if a module involves a complex and complicated concept, we can divide it into smaller scenarios and describe it separately. The domain model divides the scene whether thick or thin, the purpose is lets the reader read clearly.

3. Sketch or modeling tool is a problem

Building a domain model, using sketches or modeling tools, is a problem. According to the thought of the past RUP, modeling should use modeling tools such as rational rose to build one model after another, but agile development has completely broken the idea. Robert Martin, in his book Agile Software Development, strongly recommends using sketches for modeling, and then scanning sketches to form the final document. I've tried a lot on this, and my advice is that modeling tools are best not to use in the early stages of modeling. In the early stages of modeling, it is inevitable that the model is repeatedly modified. If you use a modeling tool, it means that you have to do a lot of maintenance for every change, and no sketches are quick and easy. When the model becomes more and more stereotyped, the modeling tool can be used to make the model more formal and easy to read and use later.