# Core Domain Chart: [Domain or product area]

> Classification of the subdomains or bounded contexts in one product area
> as core, supporting or generic, by plotting each one on two dimensions:
> how much it differentiates the business and how complex it is to model
> and run. The chart drives where to invest the best people, where to buy
> or outsource, and in which order to migrate. Structure informed by the
> Core Domain Charts technique of the DDD Crew and by the strategic design
> ideas of Domain-Driven Design (Eric Evans). Replace every `[bracketed]`
> value and every row marked *Example*. Worked examples use an invented
> online grocery retailer, the same one used in the Context Map template
> (`architecture/context-map`).

<!--
Guidance: How to use this template
- Run it as a workshop of 60 to 90 minutes with both engineers and product
  or business people in the room. Engineers can judge complexity; only the
  business side can judge differentiation. A chart scored by one side
  alone is an opinion, not a strategy.
- Score first, plot second, discuss third. The scores in section 3 make the
  positions on the chart traceable; the discussion in section 5 is where
  the value is.
- Keep one question per chart. A portfolio view, a migration-order view
  and a team view on the same picture become unreadable; copy section 4
  for each additional view instead.
- Expect movement. Today's differentiator becomes tomorrow's commodity;
  record the expected direction in section 6 and review the chart at
  least every [6 months].
-->

| Field | Value |
|---|---|
| Domain / scope | [Online grocery: basket to doorstep] |
| Chart question | [Where do we invest, buy or simplify in the next 12 months?] |
| Unit plotted | [Subdomains / Bounded contexts / Business capabilities] |
| Version | [0.1] |
| Status | [Draft / Agreed / Superseded] |
| Owner | [@domain-architect] |
| Workshop participants | [@product-lead], [@engineering-leads], [@finance-partner] |
| Workshop date | YYYY-MM-DD |
| Next review | YYYY-MM-DD |
| Related documents | Context Map (`architecture/context-map`), Bounded Context Canvases (`architecture/bounded-context-canvas`), Team Interaction Map (`architecture/team-interaction-map`) |

## 1. Purpose and decision supported

<!-- Guidance: Name the decision the chart informs and who will make it. Typical decisions: build versus buy, where to put senior engineers, which context to extract from a monolith first, which team to grow. Pitfall: drawing the chart because the method exists, with no decision attached. -->

[Purpose statement. *Example:* The retailer plans to replace its legacy
order management system and to hire two new teams next year. The chart
answers three questions for the leadership group: which contexts deserve
in-house investment, which should be bought or kept simple, and which
context to tackle first in the migration.]

Decision owner: [@cto]. Decision due: YYYY-MM-DD.

## 2. Scoring scale

<!-- Guidance: Agree the scale before scoring. Each dimension is the average of a few clue questions scored 1 (low) to 5 (high). The clues below are this template's own wording of the kind of questions the DDD Crew technique suggests; adapt them, but keep them fixed for the whole chart so contexts stay comparable. -->

Score each clue from 1 (low) to 5 (high). The dimension score is the
simple average of its clues.

**Business differentiation (D)**

| Clue | Question to answer |
|---|---|
| D1 | How hard would it be for a new market entrant to match this capability? |
| D2 | How hard would it be for an established competitor to match it? |
| D3 | How much advantage (revenue, loyalty, brand) does it give us today? |
| D4 | How much advantage could it give us if we invested further? |

**Complexity (C)**

| Clue | Question to answer |
|---|---|
| C1 | Essential complexity: how hard is the domain itself to model, with its rules, calculations and decisions? |
| C2 | Accidental complexity: how much harder is the current solution than the problem requires? |
| C3 | Operational complexity: how much difficult work happens around the software (manual processes, scale, specialist knowledge)? |

**Classification rule used in this chart**

| Class | Rule (*Example* thresholds, agree your own) | Usual investment stance |
|---|---|---|
| Core | D at or above 3.5 | Build in-house with the strongest team, model carefully, protect with clear boundaries |
| Supporting | D from 2.0 to below 3.5 | Build simply or customise a product, avoid over-engineering |
| Generic | D below 2.0 | Buy, use a managed service or open source, adapt to it rather than the reverse |

A high C2 score on a context with low D is a warning sign: the business is
paying for complexity that brings no advantage.

## 3. Scoring register

<!-- Guidance: One row per context or subdomain in scope. Record the individual clue scores so people can challenge a single number instead of the whole position. Write the main argument in the last column; a score without a reason cannot be reviewed. -->

| ID | Context | D1 | D2 | D3 | D4 | D (avg) | C1 | C2 | C3 | C (avg) | Class | Main argument |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CDC-01 | *Example:* Catalogue | 3 | 2 | 2 | 3 | 2.50 | 2 | 3 | 2 | 2.33 | Supporting | Ranges matter, but product data handling is industry standard |
| CDC-02 | *Example:* Basket and Checkout | 4 | 4 | 3 | 4 | 3.75 | 3 | 3 | 3 | 3.00 | Core | Substitution preferences at checkout are a known reason customers stay |
| CDC-03 | *Example:* Slot Booking | 5 | 4 | 5 | 4 | 4.50 | 5 | 3 | 4 | 4.00 | Core | Narrow one-hour slots with dynamic capacity are the main brand promise |
| CDC-04 | *Example:* Fulfilment | 5 | 5 | 4 | 5 | 4.75 | 4 | 4 | 5 | 4.33 | Core | Picking accuracy and freshness drive repeat orders; heavy operational work |
| CDC-05 | *Example:* Payments | 1 | 1 | 2 | 1 | 1.25 | 3 | 2 | 2 | 2.33 | Generic | Card processing is a commodity; refunds logic is the only local rule |
| CDC-06 | *Example:* Legacy OMS | 2 | 2 | 1 | 2 | 1.75 | 2 | 5 | 3 | 3.33 | Generic | Order records and invoices are standard; complexity is almost all accidental |
| CDC-07 | *Example:* Notifications | 1 | 1 | 1 | 2 | 1.25 | 1 | 2 | 1 | 1.33 | Generic | Messages to shoppers can use any managed messaging service |
| [CDC-NN] | [Context] | [1-5] | [1-5] | [1-5] | [1-5] | [avg] | [1-5] | [1-5] | [1-5] | [avg] | [Class] | [Argument] |

## 4. Chart

<!-- Guidance: Plot each row of section 3. Convert a 1 to 5 average into the 0 to 1 chart range with (score - 1) / 4, so 1.0 maps to 0 and 5.0 maps to 1. Differentiation is on the horizontal axis and complexity on the vertical axis in this template; keep the same orientation in every chart of the organisation. -->

Positions use x = (D - 1) / 4 and y = (C - 1) / 4, rounded to two decimals.

```mermaid
quadrantChart
  title Core domain chart, as-is (Example)
  x-axis Low differentiation --> High differentiation
  y-axis Low complexity --> High complexity
  quadrant-1 Core, invest and protect
  quadrant-2 Complexity without advantage, simplify or replace
  quadrant-3 Generic, buy or use a service
  quadrant-4 Differentiating but simple, guard against copying
  Catalogue: [0.38, 0.33]
  Basket and Checkout: [0.69, 0.50]
  Slot Booking: [0.88, 0.75]
  Fulfilment: [0.94, 0.83]
  Payments: [0.06, 0.33]
  Legacy OMS: [0.19, 0.58]
  Notifications: [0.06, 0.08]
```

| Context | x | y |
|---|---|---|
| *Example:* Catalogue | 0.38 | 0.33 |
| *Example:* Basket and Checkout | 0.69 | 0.50 |
| *Example:* Slot Booking | 0.88 | 0.75 |
| *Example:* Fulfilment | 0.94 | 0.83 |
| *Example:* Payments | 0.06 | 0.33 |
| *Example:* Legacy OMS | 0.19 | 0.58 |
| *Example:* Notifications | 0.06 | 0.08 |

## 5. Findings

<!-- Guidance: Write what the picture says in sentences. Look for surprises: a context the business calls strategic that scores low on differentiation, a generic context that consumes a senior team, a core context run by a part-time team. Each finding should lead to an action in section 7. -->

| ID | Finding | Evidence | Implication |
|---|---|---|---|
| F-01 | *Example:* Two core contexts (Slot Booking, Fulfilment) also carry the highest complexity | CDC-03, CDC-04 | Both need stable, senior, stream-aligned teams and careful models |
| F-02 | *Example:* Legacy OMS is the only context above 0.5 complexity that is generic | CDC-06, C2 = 5 | Complexity is accidental; replacing it is a cost and risk play, not a differentiation play |
| F-03 | *Example:* Payments has some local refund rules but no advantage | CDC-05 | Keep refund rules thin; do not let a provider model leak into checkout |
| [F-NN] | [Finding] | [Rows] | [Implication] |

## 6. Expected movement

<!-- Guidance: Strategy is a bet on the future. For each context, say where you expect it to move in 12 to 24 months and why: competitors catching up, a new product line, a regulation, a platform becoming available. Pitfall: treating the chart as a permanent label. -->

| Context | Today | Expected in [24 months] | Driver of movement | Signal to watch |
|---|---|---|---|---|
| *Example:* Basket and Checkout | Core | Supporting | Competitors are copying substitution preferences | Two major competitors offer the same feature |
| *Example:* Slot Booking | Core | Core | Dynamic slot pricing is planned | Share of orders in premium slots |
| *Example:* Legacy OMS | Generic, high accidental complexity | Retired | Migration to new Order context and a bought invoicing service | Percentage of orders still flowing through OMS |
| [Context] | [Class] | [Class] | [Driver] | [Signal] |

## 7. Decisions and actions

<!-- Guidance: Turn findings into decisions with owners. Link larger decisions to an ADR. The usual levers are team allocation, build or buy, model investment and migration order. -->

| ID | Decision or action | Based on | Owner | Record | Due |
|---|---|---|---|---|---|
| ACT-01 | *Example:* Put the two new teams on Slot Booking and Fulfilment, not on OMS replacement | F-01 | @cto | ADR-040 | YYYY-MM-DD |
| ACT-02 | *Example:* Replace OMS invoicing with a bought service, migrate order state to a new Order context | F-02 | @platform-lead | ADR-031 | YYYY-MM-DD |
| ACT-03 | *Example:* Keep Payments as a thin wrapper around the provider, with an anticorruption layer | F-03 | @payments-lead | Context Map REL-05 | YYYY-MM-DD |
| [ACT-NN] | [Action] | [Finding] | [@owner] | [Link] | YYYY-MM-DD |

## 8. Migration order view (optional)

<!-- Guidance: When the chart supports a migration, change the vertical axis question to "how hard is it to move this context out of the current system?" and keep differentiation on the horizontal axis. Contexts that are valuable and easy to move often go first, because they prove the target architecture early. -->

| Order | Context | Differentiation (D) | Ease of extraction (1 hard to 5 easy) | Reason for position |
|---|---|---|---|---|
| 1 | *Example:* Slot Booking | 4.50 | 4 | Already behind an API; high value proves the new platform |
| 2 | *Example:* Basket and Checkout | 3.75 | 3 | Depends on Catalogue prices; needs an anticorruption layer first |
| 3 | *Example:* Legacy OMS order state | 1.75 | 1 | Largest data migration; done last with a strangler approach |
| [N] | [Context] | [D] | [1-5] | [Reason] |

## Glossary and references

<!-- Guidance: Keep the definitions short and in your own words so the chart can be read by people who missed the workshop. -->

- **Core domain**: the part of the business where better software gives
  the largest advantage and where in-house modelling effort pays back most.
- **Supporting subdomain**: needed by the core and specific to the
  business, but not a source of advantage on its own.
- **Generic subdomain**: a problem many organisations share, usually best
  served by a product or service.
- **Essential, accidental and operational complexity**: complexity of the
  problem itself, of the current solution beyond what the problem needs,
  and of the work around the software.

References:

- DDD Crew, Core Domain Charts, https://github.com/ddd-crew/core-domain-charts
  (technique, clue questions and variants; checked 2026-10-30).
- Eric Evans, *Domain-Driven Design: Tackling Complexity in the Heart of
  Software*, Addison-Wesley, 2003 (strategic design, core domain
  distillation).
- Related templates: Context Map (`architecture/context-map`), Bounded
  Context Canvas (`architecture/bounded-context-canvas`), EventStorming
  Summary (`architecture/event-storming-summary`), Domain Message Flow
  (`architecture/domain-message-flow`), Build vs Buy Analysis
  (`architecture/build-vs-buy-analysis`).

## Standard and licence note

Structure informed by the Core Domain Charts technique published by the
DDD Crew (https://github.com/ddd-crew/core-domain-charts). As checked on
2026-10-30, the repository README states CC BY 4.0 while its licence file
states CC BY-SA 4.0. This template does not copy the chart image or its
text: the scoring scale, classification thresholds, tables and examples
are original to this collection, and the technique is cited by name only.
Core, supporting and generic subdomains are concepts from Domain-Driven
Design by Eric Evans. Template licence: MIT.