Bounded contexts, model integrity and architecture

1. Bounded contexts and context maps

Two further notions involving contexts complete the vocabulary of Chapter 2:

• Bounded Context: enforce a model's boundaries and make them explicit.
• Context Map: provide a global view on the domain and its contexts.

The definition of a context boundary is worth reading slowly, because it names three independent perspectives from which a boundary is real:

A context map is then a map of all the contexts in a domain and their boundaries, plus their points of contact — dependencies, homonyms, false friends — providing the whole picture of the domain.

Best practices

• Clearly identify and represent boundaries among contexts.
• Avoid responsibility diffusion over a single context: one responsible person or team for each context.
• Avoid changes in the model for problems arising outside the context; rather, extend the domain by creating new contexts.
• Enforce a context's cohesion via automated unit and integration testing, to be re-executed as frequently as possible.

2. The model integrity problem

The question posed by the lecture is: how to preserve the integrity of the model? The reasoning proceeds in four moves:

1. As the domain evolves, the software model should evolve with it, in order to maintain the coupling. (Recall Chapter 2: adherence must hold at any moment.)
2. Yet the domain rarely changes as a whole: more commonly it changes in a context-specific way.
3. Contexts are bounded, but not isolated — and so are models, which may depend on each other.
4. Therefore changes to a context and its model may propagate to other contexts and models.

Conclusion, stated flatly on the slide: domain and model changes are critical and should be done carefully.

The four model integrity patterns are the answers, and they share two purposes: preserve the integrity of the model with respect to the domain, and minimise the potential impact and reach of changes — each context as independent as possible, each change affecting as few contexts as possible.

3. Upstream and downstream: the anatomy of a relation

Context maps highlight relations among contexts, yet not all relations are equal, nor symmetric. Each relation between two contexts usually involves two ends, or roles:

• the upstream end, the one providing functionalities;
• the downstream end, the one consuming functionalities — and the downstream depends upon the upstream, but not vice versa.

Then comes the sentence that turns an architectural discussion into an organisational one:

Integration among contexts ↔ interaction among teams.

Several strategies may be employed, depending on: mutual trust among teams, ease of communication and cooperation among teams, and technical, organizational, administrative or legal constraints. The lecture even defines the term it is about to use as a variable: trust ≈ willingness to collaborate + seek for stability.

4. The four model integrity patterns

5. Layered and hexagonal architecture

The lecture opens this part with a disclaimer that should be quoted before any architecture debate:

• DDD does not enforce a particular architecture.
• Any is fine as long as the model is integer.
• Layered architectures are well suited to preserve models' integrity.
• The focus here is the hexagonal architecture, a particular case of layered architecture, well suited to DDD.

The organising rule of the whole arrangement is a single sentence: outer layers depend on innermost ones; the vice versa is not true.

Notice how the table restates a distinction from Chapter 3 in architectural terms: the domain layer must support a wide range of applications (entities are general purpose) while the application layer supports a particular use case (services are purpose-specific). The design asymmetry between services and entities is the boundary between two layers.

6. Enforcing the architecture in the code

A layering that exists only in a diagram is a layering that will be violated by the first hurried import. The lecture therefore states that layering may be enforced in the code, by mapping layers into modules, where module ≈ packaging unit — Gradle sub-projects, Maven modules, .NET assemblies — each module having its own build dependencies.

The component graph given on the slide reads as follows, with <|-- meaning "is depended upon by":

:domain        <|--  :application
:application   <|--  :presentation
:presentation  <|--  :web-api
:presentation  <|--  :message-queue
:presentation  <|--  :command-line
:application   <|--  :storage
:presentation  --|>   third-party serialization library (e.g. gson)
:storage       --|>   third-party DB client library
product        --|>   :web-api , :storage , :message-queue

Three observations make this worth memorising rather than merely reading:

• The third-party libraries appear only at the edges. The serialization library is a dependency of :presentation; the DB client library is a dependency of :storage. Neither can reach :domain, because the build system will not let it.
• The interface modules are siblings: :web-api, :message-queue and :command-line all sit on top of :presentation. Adding a fourth way in does not touch the model.
• The deliverable (product) depends on the outermost modules only, which is what makes the assembly swappable.

7. Event sourcing

The preliminaries are put as an observation about mutable entities: whenever there is a mutable entity whose state evolution over time must be tracked, state transitions can be memorised in two ways — one may track the current state, or the flow of variations.

Event sourcing is then defined as a pattern where domain events are reified into time-stamped data and the whole evolution of a system is persistently stored. The lecture calls it a perfect match with DDD, as domain events are first-class citizens — the block from Chapter 3 becomes the unit of persistence.

8. CQRS

Command-Query Responsibility Segregation is introduced as an advanced pattern for building highly-scalable applications. It leverages upon event sourcing and layered architecture to deliver reactive, eventual-consistent solutions where context boundaries can be easily enforced and the single responsibility principle is applied extensively.

The definition is one line: split the domain and application layers to segregate read/write responsibilities.

• Read model (also called view or query model): accepts queries aimed at observing the state of the system.
• Write model (also called command model): accepts commands aimed at altering the state of the system.

The two workflows

Writing. Whenever users are willing to perform an action into the system: they create a command and forward it to the write model — an object describing a variation to be applied to some domain aspect; the command is possibly validated and stored onto some database, an ad-hoc database being available in the model for storing commands.

Reading. Whenever users are willing to inspect or observe the system at time t: they perform a query on the read model, asking for the state of the system at time t (for instance t = now); commands up to time t are assumed to be reified when reading, and a snapshot of the system state at t is returned.

When are commands reified?

Reification is defined as the process of computing the state of the system at time t by applying the commands recorded up to time t. If queries and commands are stored on different databases, reification implies updating the query database — and then a nice piece of engineering advice follows: the query database should be read-efficient, the commands database should be write-efficient.

The three strategies are explicitly non-mutually-exclusive.

9. The exercises

Three exercises accompany the DDD module, on the repository github.com/unibo-spe/ddd-exercise, branch exercise (solutions on branch master). They are the practical closure of Chapters 2 to 4, and they map one-to-one onto the three themes of this chapter.

Exercise 1 — Simple Store

A simple domain keeping track of customers, products and orders:

• Customers can be companies or persons; companies are identified by a VAT number, persons by tax codes; in any case a name and email are recorded, and both may vary over time.
• Products are identified by name and type/category; they have a nominal price expressed in some currency; availability is tracked; price and available quantity may vary over time.
• Money and exchange rates: money is a decimal value plus a currency; currencies have a name, a symbol and an acronym (Euro, EUR, €; USA Dollar, USD, $); exchange rates track the conversion rate from a source currency to a destination currency at a particular moment; the information can be attained from the Internet; hence the price of each product can be computed in any currency, at any moment.
• Orders are identified by a serial number; they track the products ordered by a customer and the number of copies of each; they track when they were performed; all such information may be modified before delivery; when a new order is registered many actions should be performed in reaction; and it must be possible to compute the actual total price of an order at a particular moment, in a particular currency.

The to-do list is the workflow of Chapters 2 to 4 in miniature: read the informal domain description; identify the main concepts composing the ubiquitous language; model the domain as Java types; the model should include entities, value objects, repositories, factories and services; structure the Java types according to a module structure compliant with hexagonal architecture (put code into either the domain or the application module); sketch tests and then implementations for at least one entity, value object, factory and repository.

Exercise 2 — Trivial CQRS

A very simple repository type, the Counter: it contains one long number, initially 0; the value may be read or changed arbitrarily; whenever the value changes a new domain event of type Variation is published; however, the repository only memorises the current value of the counter.

To do: switch the design towards event sourcing, by memorising variations instead of snapshots; then implement CQRS by splitting the repository into two parts — a write-model for storing variations and a read-model for retrieving a snapshot of the counter's value in a given moment. In practice: provide implementations for the CounterReader and CounterWriter interfaces, and optionally test them.

Exercise 3 — Anti-corruption layer

A very simple domain, Tables: two-dimensional containers of Rows, where each row contains one or more String values. Functionalities for CSV import/export are missing and need to be implemented via third-party libraries — Apache Commons CSV or OpenCSV.

To do: extend the model with new interfaces supporting CSV parsing and writing; design the interfaces so that they are agnostic of the third-party libraries, without corrupting the domain model with library-specific types; implement them using one library; sketch tests; then implement them again using the other library; and use the same tests to prove the two implementations work the same way.

Check your understanding