Cloudnotes Modeling: A brief introduction to the domain model

Cloudnotes domain model is relatively simple, and does not necessarily need to adopt the domain-driven design method to solve the cloudnotes domain problem. But for the following reasons, I have used a domain-driven approach to developing cloudnotes:

1. Domain-driven is a kind of guiding model of enterprise application development, with domain model as the center of Software Development, which conforms to the basic idea of solving the problem.
2. The existing enterprise application Development framework supports the development of the domain-oriented model more and more, if you choose this way, you can make better use of the latest features of these frameworks in Cloudnotes and seek new opportunities for system development.
3. I am relatively familiar with the field-driven design, and also maintain a set of self-developed DDD development Framework Apworks. The direct reuse of the framework in cloudnotes can greatly reduce the development investment and shorten the development cycle.
4. With the new knowledge, DDD is used to guide the development of cloudnotes, and more information about DDD can be obtained.

Next, let's take a brief look at Cloudnote's domain model.

Basic model

If you are using Visual Studio 2013/2015 Ultimate (Ultimate Edition), after you open the Cloudnotes solution, You can find the Cloudnotesmodel.classdiagram class diagram design file under the Cloudnotes.design project:

Double-click the file to open the domain model Design view for cloudnotes. So far, the cloudnotes domain model is as follows:

Let's not consider these UML stereotypes such as C # class, aggregate root, which I'll cover in more detail in the next article (and, incidentally, Visual Studio support for model design and Automation code generation). It can be seen from this graph that the domain model of cloudnotes is relatively simple. Basically it can be divided into three major parts: notes, users, and customer packages (clientpackage). Perhaps you will consider whether these parts can be considered as the defining context for DDD (bounded contexts).

Defining contexts (bounded context)

Yes, we can consider dividing the cloudnotes domain model into three defining contexts:

• Note Definition context: Manage all the notes in the system
• User authentication and Authorization context: Managing system accounts, roles, and permissions
• Client Package Management context: Manage upgrade packages for all client platforms

From the ddd point of view, since the model is divided into multiple contexts, and the sub-model in context is high cohesion (defined), it is possible to produce conceptual or semantic semantics of two, which is not tolerated by the common language (Ubiquitous Language). For example, a classic example is the concept of "account" in the banking system: a banking system that provides online services, which can be roughly divided into two defining contexts: banking and online services. For banking purposes, the account represents the customer's bank accounts, and for online services, the account also represents the customer's online login, and an online login account can host multiple bank accounts, as in the case of China Merchants Bank, a Netcom account can have multiple bank card accounts and credit card accounts. So when doing system design, when encountering account concept, how to ensure the accuracy of team communication? Therefore, it is necessary to have a "component" in the domain model that can relieve this ambiguity and to help team members to be consistent in understanding and communicating the entire domain model. This "component" is usually called "context map". For a detailed introduction to defining context and context mapping, refer to this article: strategic Domain driven Design with context Mapping.

When the application needs to deal with a large area, it is necessary to introduce a defining context, from a practical point of view, using a defined context can not only use a relatively small sub-domain model in a relatively closed scope, It can also improve the performance of the application to a certain extent: for example, an operation only occurs within a sub-domain of the system, and smaller domain models can reduce the processing overhead of the system. In the development process of entity Framework Code-First (Code-first), the concept of defining context can be well introduced to divide complex domain model into relatively small and simple domain models, which have good performance not only in model design but also in performance. For more on this topic, refer to an article I translated earlier: The application of the Entity framework model in the domain-driven design definition context.

The domain model of cloudnotes is relatively simple, and although the Entity Framework is currently used in the background, it is not necessary to use the Entity Framework and may be replaced by other data persistence systems (such as MongoDB) in the future. Therefore, the concept of defining context is not applied in the manner described above.

Entity keys

Because Cloudnotes uses the Apworks framework, the entities in the Cloudnotes domain model use GUIDs as entity keys. This issue will introduce a discussion of the apworks framework. In the Apworks framework, we can see the following code:

public interface ientity{//<summary>//sets the identifier of the    entity.    </summary>    Guid ID {get; set;}}

In Apworks, the entity key is of type GUID. For the type selection of the entity key, there is a description in Vaughn Vernon's "Implementing Domain Driven Design" book. Generally speaking, there are several situations:

• user-specified entity key : This is the most intuitive way: The user provides a value directly on the interface as the key value of the entity. In general, however, the entity key value should be immutable (immutable), so when the user has selected an entity key value for an entity, it is generally not allowed to modify it. But this does not seem to be consistent with the standard user operation process: I input the things, why not let me change? Alternatively, the user can modify the value of the entity key, but this modification may also have more impact, such as when an entity key changes, references to that entity in all event data initiated by that entity are also changed. Of course, if the application needs to ensure the readability of the entity keys, we have to design a set of reasonable mechanisms to ensure that readability and feasibility will not conflict
• applications generate entity keys: Many applications generate entity keys through applications, such as the Guid/uuid generation algorithm provided by the application Development framework to generate entity keys. Using GUIDs is not only simple and relatively efficient, but more importantly, it does not need to rely on any external mechanisms outside the application, such as persistent systems. In addition, as described in "Implementing Domain driven Design", some systems with high performance requirements will cache a certain number of ID values on a separate server (or possibly a service in the background), and using GUIDs will not result in duplicate or discontinuous ID values due to ID server crashes or reboots. Because the generator of the GUID always guarantees the uniqueness of the ID value. On the other hand, if you need to generate entity key values through the application, then we need to solve the synchronization problem of ID value perfectly, but also need to consider the performance problem, further, enterprise application system is often composed of multiple applications, whether, and how to ensure the unity of entity keys in these applications, It's also a difficult thing to do.
• generating entity keys with persistence : This is a common scenario, such as an ORM system that sets key values for entities with a relational database. This is also a simple and convenient way to get the ID value, because the persistence mechanism can be borrowed to obtain the function of the ID value cache, but also to ensure the uniqueness of the ID value. But this is often not efficient, after all, the need for external systems, the performance of the persistence mechanism will also affect the performance of the application itself or even become a performance bottleneck. For large distributed enterprise application solutions, there are also problems with the synchronization and unification of ID values, such as applications A and B have different persistence mechanisms, but there is no guarantee that the entity key values should be consistent
• externally defined contexts specify entity keys : This is not a common approach and can be used in large enterprise application solutions, but not necessarily in this way. It is through the way of domain events, information passing between defining contexts, such as locally defined contexts (local bounded context) by subscribing to domain events from externally defined contexts, and through the information in the event to restore entities in the context of a local definition, The ID value is also restored to indicate that the current entity is the same entity as another object in the externally defined context.

Obviously, the apworks uses the above GUID, which is relatively simple and efficient, and the characteristics of the GUID value type can be well supported in most storage systems. Of course, it also has some drawbacks, such as poor readability, and in some storage systems neutral can not be too good. In any case, as far as the Apworks framework itself is concerned, a set of entity key-generated frameworks should be provided so that developers can extend the generation mechanism of ID values, rather than limiting the ID value type to the GUID. This is a similar mechanism in the old version of Apworks, but after considering the performance problems of boxing and unpacking, in the new version, this mechanism is canceled, and it evolves to the present situation. I will continue to improve this part of the design in the future.

Summarize

Cloudnotes's domain model is relatively simple, the implementation of the Apworks framework, and the use of visual Studio Ultimate Architecture features, the domain model for visual design and automated code generation. Perhaps in the future the domain model will be further modified, or gradually become larger, perhaps it will adopt some new technology, and generate new solutions. So far, Cloudnotes's domain model is still small, and this series of articles will first be introduced to the current model.

Cloudnotes Modeling: A brief introduction to the domain model