DDD Immersion Day 3

By | June 20, 2013

So time again for some education. This time I took the Domain Driven Design Immersion course that is held by Patrik Fredriksson (@weakreference) from Citerus.

I try to make a summery of the course here in my blog on a day to day basis.

Day 3

Today we are going to discuss Strategic Design, starting with the context map and how to map and discussion about there relation with each other.

Context Map

Map how the contexts are related to each other.


We don’t need to be as fine-grained so that we map the services inside the context, even though it might be useful in some cases. In the picture denotes D the Downstream context and U denotes the Upstream context. The downstream context has a dependency against the upstream context on (think of it as a river metaphor).

The relation between the upstream and downstream context can be classified as one of the following.

Customer / Supplier
Downstream acts as a costumer ordering changes from the upstream context.
Upstream supplies the downstream context with data that it has requested

Downstream conforms to the upstream model using it straight away.

Anti-corruption Layer
Downstream protects it model with an anti-corruption layer that translate the upstream information to the downstream model.

The upstream and downstream contexts cant succeed on there own, so if one fails both will fail. Making the relationship crucial for both success.

open-Host service
The upstream context exposes a public interface that the downstream context can use to integrate and retreav the information.

Shared kernel
A small piece of code that is physical shared between two contexts.

Big Ball of Mud
A context containing mixed models and inconsistent boundaries. Making it hard to change into something useful. It can still produce value but can be hard to integrate with.


To get the context functional we need some sort of continuous integration to create a shared view of the model as the concepts evolves inside peoples heads. This must not to be interchanged with the build environment of the project.


  1. Map what is
  2. Fix true flaws
  3. Chage reality
  4. Go back to 1

Rules for the bounded context

  • Single unified model within any one context
  • Push translation to the boarders
    • Keep interios unified
  • No duplication within the context
    • Duplication between context is ok
  • Single concistnt proces within any one context
  • Useful model needs precision design


Distilling the core domain

  • Big picture (with context map)
  • Focus effort in the right area

Generic sub-domain

  • Don’t add any value but must exist to support the core domain
  • Can typically be bought from some other company

Supporting sub-domain

  • Needed by the core
  • May be outsourced

Core domain

  • The real value of the software
  • What is the purpose with the system

Non core strategy

  • Generic – Buy it
  • Supporting – Outsource it
  • Non intrinsically complex? – Why not build it with

Benefit of distillation

  • Focus effort
  • See the forest for the trees

Here’s an example of a larger context map.

Implementing DDD Application

We want a domain model implementation that is

  • Expressive
  • Changable
  • Testable

Focus on the business domain not on the technical challenges.

The implementation must handle

  • Presentation
  • Transactions
  • Security
  • Remoting
  • Naming
  • Persistence
  • Configuration
  • Integration with external systems

Isolating the domain

  • Technical stuff out of the way
  • Keep impact of frameworks on the domain model as low as possible



That was all notes from day 3.


Context mapping

SimplestPossibleThing (m-r)
Martin Fowler on CQRS
CQRS/DDD with Greg Young
Practical CQRS in Cloud with Rinat Abdullin

6 hours of CQRS with Greg Young

Disclaimer: This is my notes and my interpretation of the information. I can really recommend going the course.

Category: DDD

Leave a Reply

Your email address will not be published. Required fields are marked *