Introduction of Context Mapping

WEBSITE DEVELOPMENT SILVERDALE —DDD (Domain Driven Design) serves the purpose of identifying the top-level architecture of the final system. The DDD(Domain Driven Design) way of expressing the top-level architecture is through the composition of multiple bounded contexts interconnected by relationships. The design artefact that defines the schema is called a context map. In ether words, the context map is the diagram that provides a comprehensive view of the system being designed.

Examining relationships between bounded contexts

Each DDD (Domain Driven Design) relationship between two bounded contexts is like an arc connecting two nodes of a graph. An upstream context influences a downstream context, but the opposite is not valid. Influence can take various forms. For sure, it means that the code in the upstream context is available as a reference to the downstream context. It also means that the schedule of work in the upstream context cannot be changed on demand by the team managing the downstream context. Furthermore, the upstream team’s responsiveness to requests for change might not be as prompt as desired by the downstream team.

Given upstream and downstream contexts, you can identify a few specific relationships:

1. The conformist relationship

2. The customer/supplier relationship

3. The partner relationship

The conformist relationship and the anticorruption layer.

A conformist relationship indicates that the downstream context depends on the upstream context, and no negotiation is possible between parties. This arrangement typically happens when the upstream context is based on some legacy code or external service. When the same team is taking care of all bounded contexts or groups are in touch, the conformist relationship might be found only for really critical pieces of code.

Strictly related to the conformist relationship is the anticorruption layer. An anti-corruption layer is an additional layer of code that gives the downstream context a fixed interface to deal with, no matter what happens in the upstream context.

An anti-corruption layer is like having a facade that provides automatic translation between distinct but interfacing data models. When you have a conformist relationship, an anticorruption layer helps isolate the code area potentially subject to changes.

The customer/supplier relationship

The customer/supplier relationship is similar to the conformist relationship. The upstream context of the two interfacing contexts is identified as the supplier, whereas the downstream context is the customer. This is the same relationship you have in the conformist relationship.

However, in this case, some negotiation is possible between the teams that manage the two contexts. For example, the customer team can share concerns and expect that the supplier team addresses them somehow.

The partner relationship

The partner relationship refers to a form of mutual dependency set between the two involved bounded contexts. Put another way; both contexts depend on each other for the actual delivery of the code. This means that no team is allowed to make changes to the context’s public interface without consulting with the other team.

An even stricter form of partnership is established when multiple contexts and multiple teams share a bounded context. This situation is referred to as having a shared kernel.

Introducing event storming

An emerging practice for effectively exploring the business domain to understand how it works and identify key events, commands, and bounded contexts is event storming. Initially developed by Alberto Brandolini, the technique involves getting developers and domain experts in a room together to ask questions and find answers.

The classic two-pizza rule establishes the correct number of people to invite. The two-pizza rule says you should never have a meeting that includes more people than you can feed with two pizzas. Generally, this limits the number of participants to less than eight.

Having unlimited modeling space

An event-storming session should occur in a location with enough modeling space to display a long timeline of events and commands, draw sketches, and jot down notes. If it’s a meeting room, you should plan to have a large whiteboard or at least a very long paper roll. Even an empty wall works.

One characteristic of event storming is colorful tape and sticky notes to add business facts, entities, values, rules, and whatever else is needed. An event-storming session consists of talking about observable events in the business domain and listing them on the wall or whiteboard. A sticky note of a given color is applied to the modeling surface when an event is identified. You also do this when other domain-specific information, such as critical entities that aggregate commands and events, are identified.

Finding events in the domain

The primary goal of event storming is identifying relevant domain events. Once a business event is found, a sticky note is put on the wall. For example, in an e-commerce scenario, you will put a sticky note on the wall, say, for the Order-Created event.

The next step is to figure out what caused each of the discovered events. For example, a domain event can be caused by a command requested by some user The Order-Created event, therefore, might be caused by the checkout command. In other cases, the event can be caused by some asynchronous occurrence, including a timeout or an absolute time. In both cases, you add a sticky note to the wall that indicates the cause. The event can also be the follower of a previously raised event. In this case, you also add another event note close to the originating event.

In the end, the modeling surface works as a timeline, and quite a bit of space is necessary to hold the sticky notes for identified events, commands that caused events, ensuing events, user-interface sketches, notes, and more.

Leading the discussion

A leader is required to lead the discussion and stimulate the act of modeling the business. The leader manages the session, stops long talks, and ensures that the focus is not lost. The leader will also advance the meeting through the various phases. The leader might or might not be a domain expert or a software expert. She is a person whose goal is to help others understand and formalize the nature of the domain. Along the way, the leader ensures that the emerging model is appropriate and accurate for everyone.

Event storming represents a quick and easy way to gain a comprehensive vision of the business domain. A valuable output of event storming is the list of bounded contexts and the list of aggregates in each context. Looking at the final sticky notes timeline, a sum is essentially the software component that handles related commands and events and controls their persistence.

DDD was introduced a decade ago to tackle the complexity in the heart of software. Although DDD principles are correct, DDD never worked in practice the way it worked in theory. After looking at what happened in Website development, Silverdale believes this mainly occurred because we missed the fact that there are two parts of DDD: strategic design and tactical design. Of the two, a strategic plan is the most critical, but too many of us focused too much on the tactics portion of DDD(Domain Driven Design).

This article is based on the DDD (Domain Driven Design)strategic design and is in a way that is technology and framework agnostic. The strategic part of DDD(Domain Driven Design) discovers the system’s top-level architecture by using a few analysis patterns and standard practices. In the following article, Website Development, Silverdale looks into more concrete supporting architectures to give form and substance to identified architectural blocks.