Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you about the use of aggregation concepts to guide the Schema design of MongoDB. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

The power of habit is powerful but often imperceptible. Often inadvertently, fall into the trap of habit without knowing it.

In our project, in order to save the analysis report and the report query conditions set by the user, we store this information as report metadata in MongoDB. The metadata to be stored includes:

Report classification (ReportCategory)

Report (Report)

Report query criteria (QeuryCondition)

A report classification can contain multiple reports, and the same report can only belong to one category. Each report provides multiple standard query conditions and multiple user-defined query conditions.

I need to design MongoDB's DB Schema for this metadata. It was initially considered to combine these three concepts and define them as a record of the metadata table. After thinking that for a report, it is necessary to add and delete the query conditions of the report frequently, and it seems that the query conditions should be separated separately. What about report classification and report? Is it appropriate to separate the report? For Document databases such as MongoDB, it is also feasible to use Report as the embedded attribute of ReportCategory, at least without data redundancy like relational databases. If you want to separate, when you need to query all the reports under a category, you have to do an extra Link.

How entangled! It seems that no matter how the design is feasible, and it seems that there is always something wrong.

While I was thinking about it, it suddenly occurred to me that for such a document-oriented NoSQL database, it would be more appropriate to use Aggregate to observe table records. The idea was as quick and sharp as lightning, crashing into the thoughts in my head, and suddenly ignited my design thinking.

Here, the so-called "aggregation" is not the concept of object relations expressed in object-oriented, but the thinking of domain-driven design (DDD) on object boundaries. With regard to the design of Aggregate, I have sorted out five design principles based on my past experience:

Aggregation, as a boundary, is mainly used to maintain business integrity, which should follow the invariants defined in the business rules (Invariant)

As a non-aggregate root entity object within the aggregation boundary, if it is possible to be called separately by other callers, it should be separated as a separate aggregation.

For the non-aggregate root object within the aggregation boundary, there should be a direct or indirect reference relationship between the non-aggregation root object and the aggregation root, and can be referenced by the object; if it must be referenced by Id, then the referenced object does not belong to the aggregation.

If an object cannot exist without another object as its master object, the object must belong to the aggregate boundary of the master object.

If an entity object may be referenced by multiple aggregates, the entity object should first be considered as a separate aggregation

These design principles are some of my thoughts when I explore the aggregate design, and I think it is of instructive value when I practice it many times. It will no longer be spread out here and will be discussed in detail in future articles. In this example alone, how should we apply these principles to think about the relationship between ReportCategory, Report, and QueryCondition?

Obviously, applying these principles, I think the tangled train of thought in front of us can be easily solved. From the perspective of business integrity, Report belongs to ReportCategory, but there is no strong constraint relationship between them, that is, there is no business invariant (Invariant). For example, ReportCategory can be an empty category without Report, or we can put aside ReportCategory and query all Report separately. If we put Report into ReportCategory aggregation, the boundary protection of aggregation becomes an obstacle and unreasonable because Report may be called separately.

Therefore, we can draw the conclusion that ReportCategory and Report should belong to two different aggregates.

Based on the fourth principle, we can ask the question: does it make sense when QueryCondition lacks a Report object? The answer is clear: without Report, there would be no QueryCondition. If there is no hair on the skin, how can it be attached! The second conclusion comes naturally: Report and QueryCondition should belong to the same polymerization. As a result, the model is about to emerge:

The above figure is a domain model, not a data model. From the point of view of domain-driven design, this is the correct open posture. So, is it suspected of mixing the domain with the technical implementation to use this domain model to guide the Schema design of MongoDB? From the design point of view, the positive solution is to consider the domain model first, and the technical implementation of DB should be designed to meet the domain model. Only when the domain model may hinder the technical implementation, or when the Schema design based on the domain model does not meet the performance or other quality attribute requirements, the domain model should be adjusted in turn. For MongoDB, a Document-oriented database, it is natural to use the concept of aggregation to guide Schema design, which not only has no sense of disobedience, but also makes the implementation of Repository more simple and natural.

In the process of project development, I made a preconceived technology selection, so I habitually began to do Schema design for MongoDB, but forgot the guiding principles of domain-driven design. Technicians are often interested in the realization of technology, so they ignore the driving force of domain design and be careful!

The above is the use of aggregation concept to guide the Schema design of MongoDB. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.