14 · Large-scale structure

When you finish this lesson you should be able to:

Propose evolving order instead of a week-one master architecture
Try responsibility layers and knowledge vs operations without cargo-culting “frameworks”
Combine structure with bounded contexts and a distilled core
Answer who sets strategy, after an honest assessment of what already exists

When the building blocks are not enough

Many modules, several contexts: people get lost. Large-scale structure is a set of rules for the whole that does not replace the model. It is a navigation aid and a constraint on where new concepts go.

Evolving order

Do not invent the grand structure in week one. Name a pattern after you see it three times. If the name fights the code, rename or drop it. Frozen structure plus a living model = fiction.

System metaphor

Useful only if experts already talk that way (“pipeline,” “ledger”). Forced metaphors become jokes. XP-style metaphor is optional here; do not invent “the hive” if nobody says it.

Responsibility layers

These are not UI / app / domain (those are technical isolation). They are horizontal slices of meaning. Evans’s family of ideas:

Potential — plans, catalogs, policies not yet applied (experiment catalog, notification policies)
Operations — day-to-day decisions (Assignment, Delivery)
Capability — what the product is in the world (Identity, Inbox)

A type still lives in the domain technical layer. The responsibility layer says what kind of decision it is.

Knowledge level vs operation level: rules about rules (the catalog) vs running assignments. Mixing them produces config objects that mutate live state by surprise. Kill switch is a catalog/potential write; serving is operations reading it—possibly with lag you named in lesson 06.

Pluggable component framework

Only when you truly have a core with replaceable parts. Most teams overbuy this and get AbstractFactoryBean. Prefer modules and contexts.

How restrictive?

Structure should make the next concept easier to place. If every change needs a council, too tight. If nobody can find anything, too loose. Refactor toward a fitting structure as the core distills.

Bringing the strategy together (chapter 17)

Three lenses: bounded contexts, distillation, large-scale structure. Honest order:

Assess what contexts and cores already exist (the map, not the slide).
Name and staff the core.
Label relationships (ACL vs conformist…).
Add structure only where navigation hurts.
Decide who may change the map. “Everyone” means nobody.

Six essentials (use as a checklist)

Evans closes with a handful of essentials for strategic decisions. In working form:

Keep the ubiquitous language alive inside each context.
Keep a visible context map.
CI inside a context; translate across.
Protect the core with people and attention.
Prefer translation to unification.
Revisit after breakthroughs—structure is allowed to change.

Who sets strategy? Someone with authority and model contact (hands-on). A committee that never ships will draw elephants.

Example

flowchart TB
  subgraph potential [Potential]
    catalog[Experiment catalog]
    policies[Notification policies]
  end
  subgraph operations [Operations]
    assign[Assignment]
    deliver[Delivery]
  end
  subgraph capability [Capability]
    identity[Identity]
    inbox[Inbox]
  end
  catalog --> assign
  policies --> deliver
  identity --> assign
  inbox --> deliver

Billing is another context, reached through an ACL, not a fourth layer on this picture.

If everything is services/, you have no structure. If you have PotentialServiceFactory, you have ceremony.

Drill (20 minutes)

Three responsibility layers in domain words.
Place eight types. Move two, or rename a layer.
Which arrows cross a bounded context? Those need a pattern (lesson 12).
Which layer holds the core (lesson 13)? If “all,” distill again.
Who owns the map (a role)? What would they refuse this quarter?