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
Conformist
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.
Partnership
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.
Workflow
- Map what is
- Fix true flaws
- Chage reality
- 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
Distillation
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
CQRS
That was all notes from day 3.
References
CQRS
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.