Core Domain Chart Template

Core, supporting and generic classification: differentiation and complexity scores, quadrant chart, findings, expected movement, decisions

ArsitekturStandarDDD Crew Core Domain Charts; Domain-Driven Design (Evans)core domain chartDiperbarui 29 Okt 2026

Buka di editorUnduh .md

Cara menggunakan: Use it when deciding where to invest, buy or simplify across bounded contexts. Agree the scoring scale first and score with engineers and business people together. The main pitfall is treating the chart as a permanent label instead of reviewing expected movement.

Pratinjau

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).

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

[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

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

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

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

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

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

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

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)

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

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.

Templat terkait

Arsitektur