Ddd practice entry point (2)

Prerequisites: support for large systems, change of application system development ideas, and DDD practice (I)

Starting with a large proportion of the structure, the system has been built. We all know that the demand is constantly changing and deepening, at the beginning, it was naturally a fuzzy large scale structure that had a preliminary understanding of the system to be carried out and clarified the requirements in the process of continuous refinement. The previous article roughly described the main issues. We can see that there are two main parts: Application Form management and approval transfer, both of which are associated with the application form, but the focus is different, the focus of Application Form management is to maintain the information of the application form, and the approval flow is mainly based on part of the information of the application form, so the model of the application form is somewhat different.

When domain models are not uniform, there may be some problems, such as limiting integration, increasing communication costs, and seemingly not elegant. However, full unification of large-scale system domain models is not a feasible economic and effective approach. Forced unified model may encounter some problems:

1. There are too many modifications to the legacy system model, which is highly risky;

2. coordinate different models used by multiple groups to unify the model. The cost is too high and the overhead is too high;

3. Some modules with special requirements may have to use models that cannot fully meet the requirements. Instead, they can only describe the unsatisfied behaviors in other places;

4. Trying to use a model to meet everyone's needs may cause the model to contain too complex choices and make it difficult to use.

It is not a good way to use a unified model. In this case, you need to mark the boundaries and relationships between different models. Bounded context is used to define the application scope of each model, and the context graph is used to give the overall view of the project context and the relationship between them. The application form management and process flow can be developed in two contexts respectively. It should be noted that this will lead to some problems: the concept of repetition and the false same source. The concept of repetition is that two model elements represent the same concept, and each time the concept changes, two places must be modified. A false same-source uses the same term for different concepts. These situations are mostly caused by unclear context boundaries.

Context graphs can clarify the boundaries of contexts. Note that codes between contexts should not be reused as much as possible. Adjacent contexts do not have to keep the same pace. integration between contexts must be implemented through interfaces or transformations. Identifies the role of each model in a project and defines its bounded context. Includes implicit models of non-object-oriented subsystems. Name each bounded context and add the name to the common language. Describes the contact points between models, clarifies the transformations required for each communication, and highlights the shared content.

There is no shared content in the figure, but the application form delegates the required condition information and flow task to the process for processing. The condition information contains the model of the flow required application form, however, the application model is different from the Application Model in the document context. This is only one-way information transfer. If there is an interaction, the intermediate transfer condition requires two-way information conversion. In addition, multiple models may encounter some obstacles during integration. Some Existing models are used to solve these obstacles, such as sharing the core, followers, isolation layer, and separate way (independent ), open host service and published language. These modes are based on the actual situation. You may not copy the books here if you encounter them in the future. As the project progresses, the context map organization mode may change with the selection of these modes. In this transformation process, the complexity of the model can also be managed by means of a large proportion of the structure and refining the core domains into common subdomains. If there are some refined patterns, I may sort them out separately, because this time we only use an abstract core, so we will introduce them together with other processes.