Boundaries & Responsibilities:Teams, Apps, API and Data

Agenda

• Strategic Design

• Bounded Context and Context Maps

• Integration Strategies & Recipes

• Data Ownership

• Integrity & Consistency

• Duplication

Strategic Design

Why?

• Scaling up complex domain models

• Total unification of the domain model for a large system

will not be feasible or cost-effective

• Modularity without losing benefits of integration

Design and Politics Often Intersect

Strategic Design

What?

• Need for a systematic, evolving design strategy

• Doesn’t happen by itself or through good intentions

• Proactive decisions about what should be unified

• Pragmatic recognition of what’s not unified

Bounded Context

• Defines the range of applicability of each domain model

• Multiple models coexist and apply in different contexts

• Defines consistency boundaries

Bounded Context

Bounded Context Not Defined

• Unclear in what context model should be applied

• Unclear in what context model should not be applied

• Lack of focus and confusion by issues outside

Bounded Context

How?

• Explicitly define a scope of a particular model

• Explicitly set boundaries

• Team organization

• Usage within a specific application

• Physical manifestation (codebase and DB schema)

Bounded Context

Clarity & Freedom

• Keep the model consistent within its bounds

• Team responsible for the model deals with the whole

lifecycle of each object, including persistence

• Teams don’t get distracted or confused by issues outside

Recognizing Splinters

Indicators

• Confusion of domain language

• Code interfaces don’t match up

• Duplicate concepts

• False cognates

Context Map

• Project’s contexts

• Relationships between contexts

Context Map

• Identify each Model on the project

• Define Bounded Context

• Name each Bounded Context

• Describe points of contact between models

• Outline explicit translation

• Highlight any sharing

Context Map

Reflects:

• Team structure

• Management structure

• Product strategy

• Timelines

• Trust

• Physical office space

Context Map

MAP THE TERRAIN!

Context Map

Context Map

• Bounded Contexts partition should be based on cost-

benefit trade-off:

• Independent team action

• Direct and rich integration

Larger Bounded Context

• Flow between user tasks is smoother (unified model)

• Coherent and easy-to-understand model instead of two

distinct ones plus mapping

• Translation between two models can be difficult

• Shared language fosters clear team communication

Smaller Bounded Context

• Communication overhead between developers is

reduced

• Continuous integration is easier with smaller teams and

code bases

• Different models can cater to special needs

• Ubiquitous language dialects can be encompassed by

smaller models

Technical Considerations

• Deployment

• Versioning and backwards compatibility

• Data migration

• Environments

Integration Strategies and Recipes

• Shared Kernel

• Customer/Supplier

• Conformist

• Open Host

• Published Language

• Anticorruption Layer

• Separate Ways

Integration Strategies and Recipes

DECISIONS ARE NOT

IRREVERSIBLE

Data Ownership

• Data Integrity

• Data Duplication

Data Duplication

Is data duplication BAD?

Data Duplication

• Staleness

• Inconsistency

Data Duplication

The data may be stale…

but is that really an issue?

Data Integrity

• Different data has different requirements

• Product Specifications

• Product Assets

• Product Pricing

• Product Recommendations

• Cost-benefit analysis