Implementing Domain-Driven Design (Study Group) Chapter 3 - Context Maps

Chapter 3 - Context Maps
Speaker: Eason Kuo
Date: 2019/04/10 @ Taiwan iDDD Study Group
Why Context Maps Are So Essential

Define business domain to Problem
Space, distinguish each business
subdomain
By ubiquitous language, find the
boundaries of each subdomain and
distinguish the Bounded Context
Recap Bounded Context
© 2019, Eason Kuo, Taiwan iDDD Study Group

Define business domain to Problem
Space, distinguish each business
subdomain
By ubiquitous language, find the
boundaries of each subdomain and
distinguish the Bounded Context
Recap Bounded Context
Okay Everything seems great, right?

But !

Found Subdomain & Bounded Contexts
Is Enough?

No.
There are some issues you should consider…

Issue 1 : More Complex Scenario, More Unclearly Bounded Context

Issue 2: Organization Complexity
Sample from Internet, Not I Say..

Issue 3: Large team size or multiple development teams

Issue 4: Distributed or offshore team

Issue 5: External, Separate Systems

Issue 6: Legacy Systems

So, We need Context Maps

What is Context Maps ?

Context Maps Description
Context Maps could reflect the collaborative or even
organizational teams relationships between different
Bounded Contexts in your systems.
What is Context Maps?

A simple Context Maps draws the
U (Upstream) and D (Downstream)
Shows Bounded Contexts
integration relationship.
Upstream and Downstream

Focusing on what’s happening
between different bounded
contexts.
Inter-communication with teams.
Discover relationship / influence
from Bounded Contexts mapping
to your teams or others partners.
The helping from Context Maps

The Benefit for Drawing
Context Maps

• A Context Map captures the existing terrain
and landscape will change as your current
project progresses, you can update it.
• we could to include other items such as
Modules, Aggregates or team allocation to
assist us.
• All Information, Context Maps can put into
reference document / wiki if it has value.
The Benefit for Drawing Context Maps

• If detail too much, it’s helpless and
fewer people want to use the Map, assist
team to communication is important.
• It can providing views of the enterprise
not otherwise available
• Could find the some bottleneck like
integration, management .

Relationship for Context Maps

Relationship
Relationship for Context Maps
Different Relationship
and communication
for everyone with you

Is this important for
relationship ?

Discovering potentially crisis

Helps to integrate different bounded contexts with other teams

Relationship Patterns for
Context Maps

• Different teams / separate bounded
context crossover in terms of
domain concepts and logic.
• With an explicit boundary subset of
the domain model that the teams
agree to share.
• shouldn’t be changed without
consultation with the other team
• At this case, recommended that
they do so as a partnership. Not distinguish U/D Relationship
1. Shared Kernel
Relationship Patterns for Context Maps

• When teams in 2 Contexts will
succeed or fail together
• coordinated planning of
development and joint
management of integration.
• cooperate on the evolution of
their interfaces to accommodate
the development needs of both
systems.
Not distinguish U/D Relationship
2. Partnership

• teams are in an upstream-
downstream relationship.
• Upstream teams could
interdependently developing
feature.
• Downstream teams will be
influence from upstream.
3. Customer – Supplier

• Also upstream-downstream
relationship.
• Upstream team has no
motivation to provide for the
downstream team’s needs.
• Downstream is helpless.
4. Conformist

• If 2 sets of functionality have no
significant relationship
• cloud be completely cut loose from
each other.
• Declare bounded context have no
connection to others at all.
• Enable to find simple, specialized
solutions within the scope
5. Separate Way

6. Big Ball of Mud

• Happens on Shared Kernel, Partnership,
Customer-Supplier can not implement.
• Downstream build a translation layer
(Adapter) to protect inner domain
model.
• The ACL also be a interface layer to
cooperate with external system,
decrease changed.
7. Anticorruption Layer (ACL)

• Define a protocol that gives access to
your subsystem as a set of services
• Open the protocol so that all who need
to integrate with you can use it.
• Other systems or components that
communicate with OHS will use
transformation layer for translating
our model into terms of their own,
similar to the ACL.
8. Open Host Service (OHS)

• The translation between the models of
two Bounded Contexts requires a
common language
• Use a well-documented shared language
that can express the necessary domain
information, translating as necessary into
and out of that language.
• Publish Languages often combined with
Open Host Service
9. Public Language (PL)

Sample Link DDD "Cargo" Sample Application
Example – DDD Cargo Sample

So far so good.
We can do some Practice.

20 mins Practice

Example – Insurance Company
20 mins Practice
P M s I u M A -A D D r a W r
- CDA B 5 5 D t
W t s - CDA BC Io M W S c W y
- CDA B 3 > 3 B 5 5 D t
W x M4 6 b W d k f
1A> 5 5 D t
W t I m -A DB5 DC 1A> C 2 C 5 5 D A D D n
M . 6D -A>> D A -A D D I
. 6D -A>> D A g
W I m -A DB5 DC 1A> C e g s I
( 2 C 5 5 D t
W 1A> 5 5 D -A D D vy I R -A DB5 DC 1A> C
) 1B D -A D D l t
W x S W 1 I t l I f I . 6 D 1A> C
- CDA BC I i

a n B 9 2 2 9 it C Ph od
e M 9 2 2 9 pS 9 1 x m
Dl ru pP U w
s 9 1 K 0 1 9 1
. 61 9 -1 Rx / 1 2 6
2. Partnerships
3. Customer-Supplier
4. Conformist
5. Separate Way
6. Big Ball of Mud
7. ACL
8. OHS
9. PL
. 61 9 -1
20 mins Practice

Sample Link Insurance Company Example
20 mins Practice

Mapping the IDDD Three Bounded
Context - SaaSOvation

• CollabOviation - social collaboration suite product.
• enables register to publish content.
• Using forums, shared calendars, blogs, wikis
• IdOvation - A reusable identity & access management model.
• provides secure role-based access management for
registered users
• ProjectOvation - An agile project management product.
• create project management assets
• analysis and design artifacts, and track progress
Recap Three Bounded Context Product
Mapping the IDDD Three Bounded Context - SaaSOvation

• Unclear part for user permission in Collaboration Context
• Analyze and split unclear part (user permission) from Collaboration Context
• Put user permission part to Identity & Access Context
Collaboration Context Mapping Example
Mapping the IDDD Three Bounded Context - SaaSOvation

Code Implementing for
Context Maps Representation

• OHS - Implementing like API using REST, RPC,
SOAP or Message exchange.
• Even old way like Files, database is OHS (not
recommend)
• PL – represent Domain concept.
• Like XML/ JSON
• if you want to use User Interface, also HTML is Ok.
• Can be used in Event-Driven Architecture by Domain
Event to deliver message for subscriber.
• ACL – Define Domain Service or Repository to
request OHS and return PL
• Build a translation interface like Adapter and translate
to Value Object
OHS/PL and ACL for Implementing.
Code Implementing for Context Maps Representation

• UserRoleAdater and CollaboratorTranslator
representation and translate it, creating the
appropriate Value Object instance –
Moderator.
• CollaboratorService is Domain Service
• But why creating Value Object ?
Collaboration Context with Identity & Access Context

• In order to achieve greater degree of
autonomy, make dependent state is already
in place in our local system.
• In DDD, not use Cache. DDD create local
domain objects translated from the foreign
model, maintaining only the minimal
amount of state needed by the local model
(p795 - Integrate with Minimalism)
• To get the state in the first place we may
need to make limited.
Autonomy - Value Object for minimal amount of state

Agile PM Context with Identity & Access Context

• In Agile PM Context, each Domain Service
map to its Translator, and use Translator to
create Value Object to achieve minimal
mount of state data.
• Actually there is not one single
CollaborationAdapter. It is just a
placeholder for the several needed, it may
changes by times.
Agile PM Context with Collaboration Context

• In Agile PM Context, a feature is “when
system creates the Product with a Forum
and Discussion. ”
• Agile PM Context needs objects that don’t
exist yet and won’t exist until it requests
them, it is Potential obstacle to autonomy.
• Because we depend on the availability of
the Collaboration Context in order to
create resources remotely.
Dependent on other Context to do Action issue

• Using Standard Type Value Object
be implement States and default
state, to get default Value Object.
• If The state is READY, Then it’s can
access.
• In here, use Enum to list different
state.
Solution Method – Standard Type for Value Object

Sharing Your Reward
10 mins with your group

Context Maps
Recap Chapter 3

Context Maps could reflect the collaborative or even
organizational teams relationships between different Bounded
Contexts in your systems.
Drawing your Context Map using 9 Relationship Patterns and
changes as your current project progresses.
Using ACL or OHS/PL could assist you to translate outer Bounded
Context , decrease unnecessary changes and protect your Domain
Model in your Bounded Context.
Recap for Context Maps (1)

Try to make your Bounded Context could achieve a greater
degree of Autonomy
Autonomy - make dependent state is already in place in
our local system, maintaining only the minimal amount of
state needed by the local model.
Using Value Object / Standard Type skill to keep minimal
amount of state (More detail : Value Object in Chapter 6 )
Recap for Context Maps (2)

Thanks!

Implementing Domain-Driven Design (Study Group) Chapter 3 - Context Maps

More Related Content

What's hot

Similar to Implementing Domain-Driven Design (Study Group) Chapter 3 - Context Maps

More from Eason Kuo

Recently uploaded

Implementing Domain-Driven Design (Study Group) Chapter 3 - Context Maps