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

This book is Eric Evans 'lexicographical reference to Domain-Driven Design: Solutions to Software Core Complexity, which provides a quick look up of the concepts and concise explanations in Domain-Driven Design.

Other articles in this series:

Domain Driven Design Reference (Part 1)

Domain Driven Design Reference (2)-Making the Model Work

Domain Driven Design Reference (III)-Building Blocks of Model-Driven Design

Domain Driven Design Reference (IV)-Flexible Design

Domain Driven Design Reference (V)-Context Mapping for Strategic Design

binding context

A description of the definition and scope of a particular model (usually a subsystem, or the work of a particular team).

the upstream-downstream

The relationship between the two groups is that the behavior of the "upstream" group affects the project success of the "downstream" group. But downstream behavior does not significantly affect upstream projects. (For example, if two cities are along the same river, pollution from the upstream city mainly affects the downstream city.)

Upstream teams can succeed independently of the fate of downstream teams.

interdependent

Two software development projects must be delivered in different contexts for either to be considered successful. (When two systems depend on each other for information or functionality, we usually try to avoid building the items we see as interdependent.) However, there are also interdependent projects, and system dependencies only go in one direction. When a dependent system has no other systems integrated with it, it has little value, perhaps because it is the only place to use it, and failure to provide a dependent system causes both projects to fail.)

free

In an ideal software development context, whether development efforts succeed or fail in other contexts has little impact on their own delivery.

context map

In order to plan strategy, we needed a realistic, wide-ranging model development view that extended to our projects and other projects we integrated.

In the absence of a global view, individual bounding contexts leave some problems. The context of other models may still be ambiguous.

People on other teams are unaware of context boundaries and unconsciously make changes that blur edges or complicate internal connections. When connections have to be made in different contexts, they tend to × each other.

Even when boundaries are clear, relationships to other contexts limit the nature of the model or the speed at which it can change. These constraints need to be expressed through non-technical channels and are sometimes difficult to relate to the design decisions they are influencing.

Therefore:

Identify each model in use in the project and define its bounding context. This includes implicit models of non-object oriented subsystems. Give each bounding context a name and make its name part of the common language.

Describe the points of connection between models, list explicit translations of any interactions, highlight any sharing, isolation mechanisms, and degrees of influence.

Map an existing domain scope. The conversion will take place later.

This map can be the basis for an actual design strategy.

In the next few pages, the description of relationships becomes more specific, with a common set of relational patterns between bounding contexts.

Partnership *

Collaborative relationships usually occur when teams in two contexts succeed or fail together.

In an independent context, lack of collaboration between interdependent subsystems can lead to delivery failures for both projects. A key feature missing from one system may prevent another from delivering. An interface that does not meet the expectations of other subsystem developers can cause integration failures. A mutually agreed upon interface may become too awkward to slow down the development of client systems, or difficult to implement, slowing down the development of service terminal systems. The defeat resulted in the defeat of two projects.

Therefore:

If failure of development in either context would result in failure of delivery for both contexts together, a collaborative relationship is established between the teams responsible for both contexts. Develop processes for coordinated development and joint management integration.

Teams must collaborate on the evolution of their interfaces to accommodate the development needs of both systems. Interdependent features should be arranged so that they are completed in the same release.

In most cases, developers do not need to know the models of other subsystems in detail, but they must coordinate their project plans. When development in a context hits a snag, the problem needs to be studied jointly to find an urgent design solution that does not unduly harm either party.

In addition, a clear process is needed to manage integration. For example, you can define a special test suite to prove that the interface meets the expectations of the client system, which can be run as part of continuous integration on the server system.

shared kernel

Sharing models and related code is part of a very close interdependency that can speed up design work or break things that are shared.

When functional integration is limited, the overhead of continuous integration for large contexts may be considered too high. This can be particularly evident when the team does not have sufficient skills or organizational structure to sustain continuous integration, or when the individual teams are too large and clumsy. Thus, independent bounding contexts can be defined and multiple teams formed.

Once separate, uncoordinated teams work on closely related applications, they may move forward for a while, but the products they produce may not fit together. Even partner teams end up spending a lot of effort on translation layers and transformations, duplicating those efforts and losing the benefits of common language.

Therefore:

Specify, with explicit boundaries, a subset of the domain model that the team agrees to share. Keep this kernel as small as possible.

Within this boundary are subsets of the model, subsets of code, or database designs associated with parts of the model. This explicitly shared content has a special status and should not be changed without consultation with other teams.

Define a continuous integration process to keep the kernel model compact and consistent with the team's common language. Often it integrates functional systems, although less often than continuous integration in teams.

Customer/Supplier Development

When two teams are in an upstream/downstream relationship, the upstream team may succeed independently of the fate of the downstream team, and the downstream requirements will be addressed in a variety of ways with widespread negative consequences.

Downstream teams may be helpless, at the mercy of upstream priorities. At the same time, upstream teams may receive inhibitions for fear of disrupting downstream systems. A cumbersome change request process with complex approval processes does not improve the problems of downstream teams. If the downstream team has veto power over change, the upstream team's free evolution stops.

Therefore:

Establishing a clear customer/supplier relationship between the two teams means putting downstream priorities into upstream planning. Negotiate and budget tasks for downstream needs so that everyone understands commitments and timelines.

Agile teams can have downstream teams play the customer role of upstream teams in planning meetings. Jointly developed automated acceptance tests verify the intended interface from upstream. Adding these tests to the upstream team's test suite as part of its continuous integration will give the upstream team the freedom to make changes without worrying about downstream side effects.

submissive

When two development teams have an upstream/downstream relationship, there is no incentive upstream to help with the downstream team's needs, and the downstream team is powerless. Altruism may prompt upstream developers to make commitments, but they are unlikely to materialize. It is believed that these good intentions will lead downstream teams to make plans based on features that are not available. Downstream projects will be deferred until the team finally learns to accept what the upstream has to offer. Tailored interfaces to the needs of downstream teams are unlikely.

Therefore:

By strictly adhering to the upstream team's model, the complexity of transitions between bounding contexts is eliminated. Although this limits the style of downstream designers and may not produce an ideal model of the application, choice consistency greatly simplifies integration. In addition, you will share a common language with the upstream team. Upstream is in the driver's position, so it's good to make their communication easier. Altruism may be enough for them to share information with you.

anti-corruption layer

The translation layer can be simple, even elegant, when interfacing well designed bounding contexts with collaborative teams. However, the transformation becomes more complex when control or communication is insufficient to enable shared kernel, partner, or customer-vendor relationships. The translation layer adopted a more defensive tone.

A large interface provided to an upstream system may eventually completely subvert the intent of a downstream model, causing it to be modified to mimic models of other systems in a particular way. Legacy models are often weak (if not big mud balls), and even explicitly designed exceptions may not fit the requirements of the current project, making it impractical to follow upstream models. However, this integration can be valuable or even necessary for downstream projects.

Therefore:

As a downstream client, create an isolation layer that provides the functionality of the upstream system to the system based on your own domain model. This layer communicates with another system through its existing interface, requiring little or no modification to the other system. Internally, this layer requires a unidirectional or bidirectional transformation between the two models.

Open hosting services

Typically for each bounding context, you will define a translation layer for each part that you must integrate with components outside the context. This approach of inserting translation layers for each external system avoids model corruption at minimal cost in cases where integration is one-off. But when you find that your subsystems have higher requirements, you may need a more flexible approach.

When one subsystem must be integrated with many other subsystems, customizing a translation object for each subsystem can get the team bogged down. There is more and more maintenance, more and more worry about when changes will happen.

Therefore:

Define a protocol that will access your subsystems as a set of services. Open the protocol so that everyone who needs to integrate with you can use it. Enhance and extend protocols to handle new integration requirements, unless a team has special requirements. The one-time translation object is then used to enhance the protocol for this particular case so that the sharing protocol remains simple and consistent.

This puts the service provider in an upstream position. Each client is downstream, and usually some of them will comply with the rules, and some will establish an anti-corruption layer. A context with an open hosting service may have any relationship to a context other than its client.

common language

A common language is required to translate between two bounded context models.

Converting directly to an existing domain model may not be a good solution. These models may be overly complex or poorly decomposed. Maybe what they say is illegal. If one of these languages is used as a data exchange language, it is effectively frozen and unable to respond to new development requirements.

Therefore:

Using a documented common language, necessary domain information can be expressed as a common communication medium and translated into the language as needed.

Many industries have established a common language in the form of data interchange standards. Project teams also develop their own for use within their organizations.

Common languages are often combined with open hosting services.

divide and rule

We must be ruthless in defining needs. If there is no significant relationship between the two sets of functions, they can be completely separated from each other.

Integration is always costly, and sometimes the benefits are small.

Therefore:

Declaring a bounded context so that it is completely independent of other contexts allows developers to find simple, specialized solutions within this small scope.

big ball of mud

When we investigate existing software systems, we try to understand how different models are applied within defined boundaries, and we find that some systems (usually large systems), models are mixed, and boundaries are inconsistent.

In systems without boundaries, it is easy to get bogged down in trying to describe the context boundaries of the model.

Well-defined contextual boundaries arise as a result of intellectual choice and social forces (although those who create systems may not always be consciously aware of these causes at the time). When these factors are missing or absent, multiple conceptual systems are mixed together, making definitions and rules ambiguous or contradictory. As features are added, the system works according to additional logic. Dependency crisscross. Causality is becoming harder to trace. Eventually, the software congeals into a big ball of mud.

In some cases, the large ball of mud is actually very practical (as described in Foote and Yoder's original text), but it almost completely prevents the acumen and precision required for useful models.

Therefore:

Draw a boundary around the entire mess and designate it as a large ball of mud. Do not attempt to apply complex modeling in this context. Be wary of the tendency of this system to spread to other contexts.

(See http://www. laputan. org/mud/mud.html.) Brian Foote and Joseph Yoder

Author: Zachary_Fan

Source: www.cnblogs.com/Zachary-Fan/p/DDDReference5.html

If you want to get the message push of personal self-written articles in time, please scan the QR code below ~.

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.