Core Domain Charts: plotting your domains by complexity and differentiation
A tool for collaboratively finding your core domains - strategic business differentiators
At a glance
- What is it?
- Core Domain Charts is a template and technique for placing bounded contexts on a two axis chart so a team can argue about which parts of the system deserve investment. It ships as documents and images rather than software, and it deliberately stays subjective.
- Who is it for?
- Core Domain Charts suit teams that need a shared, arguable picture of where their competitive advantage sits, and that want the conversation to happen across engineering and product rather than inside one discipline. It does not suit a team looking for an objective complexity metric, because the project is explicit that the judgement is subjective and strategic, and it is not a software dependency since there is nothing to install.
- Can I use it commercially?
- Yes, with credit. CC-BY-SA-4.0 allows commercial use as long as you credit the authors and indicate what you changed. It is written for creative content, so check how it applies to any code.
- Is it still maintained?
- Yes. The repository last received commits 63 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on October 24, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A chart that puts business value next to technical load
Core Domain Charts are a way of placing each subdomain or business capability on a chart, using two axes that carry the two questions a team keeps arguing about: how complex the thing is, and how much the business differentiates on it. The stated purpose is to visualise the strategic importance of each part of an architecture so that architectural decisions can be made in a way that aligns with the business model.
The definition the project gives of a core domain is where the expected ROI is greatest and where the highest focus belongs. The chart then makes the other domains visible as well, which matters because the ones that get built and maintained are rarely the ones with the highest return.
The project is candid about the point of the exercise. It calls the true power of the technique the conversations it triggers, especially cross-discipline, and it separates the two kinds of judgement involved: complexity is something engineers can gauge, while differentiation is provided by product managers and business stakeholders. A chart that only engineers fill in tends to reproduce the same ranking they already believe in, which is why the technique works as a group exercise rather than an analysis step.
It is worth being clear about the category of thing this is. The repository is a set of documents, images and examples, with `resources/` holding the chart templates, `docs/` holding the guidance, `examples/` holding worked cases and `translations/` holding a Brazilian Portuguese version. There is no build, no dependency and nothing to install.
Three chart variants, and the rule against one diagram to rule them all
The usage guidance opens with a warning that is really the core instruction: do not try to visualise all the possible information in a single diagram. The project then presents several versions showing different types of information, and the point is that you choose the flavour that matches the conversation you need to have.
The simplest flavour is the (Sub)Domain or Bounded Context Portfolio. You plot each of your subdomains or bounded contexts on the chart, and that is all. The stated value is a relative sense of ordering between them, which is modest but real, since most teams have never written their domains down in a comparable form.
The second variant augments the chart with the dependencies between your bounded contexts and the type of Team Topologies Interaction Mode in play. Here the chart stops being a map of importance and becomes a sociotechnical map: which contexts depend on which, and whether the relationship between two teams is a collaboration, a customer-supplier arrangement or something more awkward.
The third variant is the one with the most surprising reuse. With a slight change to the y-axis label, the same chart is used to plan the order in which you migrate from your current architecture to your target architecture. The charts become a sequencing tool: the same two axes that rank domains by strategic value also rank the steps of the migration, which is a neat trick and the clearest argument for keeping the template around.
The question list is the real content of the method
Since the chart is subjective, the value of the project is in the prompts it gives for reaching a shared judgement. The documentation is unusually careful to set expectations: measuring complexity and differentiation is hard and usually quite subjective, strategy is a bet on the future, and you can never be sure exactly how complex or differentiating something will turn out to be. The claim is narrower, that there is still a lot of value in discussing and visualising your beliefs about complexity and differentiation.
The complexity side is split into three forms. Essential domain complexity is how difficult it is to design a conceptual model for the domain and build and maintain it as software. Accidental technical complexity is whether the current technical solution is more complex than it needs to be to provide the current functionality. Operational complexity is whether complex processes, calculations and decisions happen outside the software, which is the kind that software teams systematically underweight.
On differentiation, the questions run from how hard it would be for a new entrant to match or exceed the capability, through how hard it would be for an existing competitor to do so, to how much advantage is currently derived from the subdomain in revenue, brand and engagement, and how much could potentially be derived from it. Two more push toward risk: what damage would occur to the brand if major or recurring failures happened in the domain, and which Cynefin domain it falls within.
The list is a checklist to argue with, not a score to compute. Nothing in it produces a number, and the chart is filled in after the discussion, not before.
Where the two axes come from and why the y-axis label moves
The chart template is the object the method runs on. It is distributed as an image in the repository's `resources/` directory, including a template file and a second variant used for the architecture migration case, and the worked examples live as markdown files under `examples/`, with `first-to-market-core.md` and `pioneers-run-experiments.md` among them.
Those examples matter more than they look. The technique is described as inspired heavily by Wardley Mapping and by Team Topologies, and the examples are the part that shows what a filled chart looks like when it is argued properly. The project also invites pull requests with your own examples, which means the catalogue of cases grows by contribution rather than by curation.
The migration variant deserves a second look because it shows the chart is not bound to one meaning. When the same axes carry migration sequencing instead of strategic value, the labels change rather than the geometry. In practice that means the vertical axis is the one you rename for that exercise, since the project describes it as a slight tweak of the y-axis label rather than a redraw.
For teams already using Team Topologies, the interaction mode overlay is the natural first extension, because the same bounded contexts that appear on the chart are the units the interaction modes are defined over.
A complementary tool rather than a competitor
The project points to an alternative and complementary approach for one specific question. For assessing process complexity, it refers to Bernd Rücker's Process Automation Map. The framing is deliberate, that the two are alternatives and complements, and the split of labour is sensible: the Process Automation Map covers the processes side of a system, while the Core Domain Chart covers the domain side and its strategic weight.
That comparison also clarifies what Core Domain Charts are not. They are not a measurement instrument, and they are not a replacement for a value stream analysis or for any technique that traces a process end to end. They are a positioning tool for domains, with the conversation as the deliverable.
The related reading listed by the project follows the same pattern of building on other people's work rather than replacing it, with links on core domain patterns, on visualising sociotechnical architecture with DDD and Team Topologies, and on the two inspirations already named.
A useful contrast is with a purely engineering framing of the same problem, where a team ranks its services by code size, coupling or change frequency. Those measures are easy to collect and quietly answer a different question, since they track how much work the code is rather than where the business advantage sits. The chart is designed to force the second question to be asked out loud, with product and business people in the room.
The limitation is the mirror image of the method's strength. If the room does not include stakeholders who can answer the differentiation questions, the chart degenerates into an engineering ranking with two axes and a nicer look.
Licence wording, translations and the limits of the repository
The licence needs care, and there is a discrepancy worth resolving before you reuse the templates. The project records CC-BY-SA-4.0 as its licence, while the text in the README describes the work as licensed under a Creative Commons Attribution 4.0 International License, with the CC BY badge. ShareAlike and plain Attribution are different obligations, and the file `LICENCE.md` at the root is the place to check which applies to the templates and images you copy. This is a description of the difference between two licences rather than advice on your obligations.
The repository is small and mostly textual. Alongside `README.md` there are `docs/`, `examples/`, `resources/` and `translations/`, and the translations directory holds a Brazilian Portuguese README, which tells you the project has been used by teams that do not read English. There is no issue tracker convention to copy, no tooling and no contribution guide beyond the invitation to open an issue or send a pull request with examples.
On maintenance, the repository is not archived and the last push was on 2026-08-23. No GitHub releases are published, so there is no version to pin and nothing to upgrade in the usual sense. For a technique rather than a dependency, that is a reasonable trade: the artifacts are stable, and adopting the current version of the chart template is the whole of the update.
Editorial conclusion
Core Domain Charts suit teams that need a shared, arguable picture of where their competitive advantage sits, and that want the conversation to happen across engineering and product rather than inside one discipline. It does not suit a team looking for an objective complexity metric, because the project is explicit that the judgement is subjective and strategic, and it is not a software dependency since there is nothing to install. Before reusing a chart, check the licence wording in LICENCE.md, because the recorded licence is CC-BY-SA-4.0 while the project text describes a Creative Commons Attribution 4.0 licence, and remember that the last push was on 2026-08-23.
Frequently asked questions
What do the two axes of a Core Domain Chart represent?
They represent complexity and differentiation, so each domain is placed by how hard it is to build and maintain and by how much the business differentiates on it. The documentation stresses that both judgements are subjective and that the value lies in the discussion.
What are the different versions of the Core Domain Chart?
There are several, and the project asks you to pick one rather than combine them. The simplest plots subdomains or bounded contexts for a relative ordering, one variant adds bounded context dependencies with Team Topologies interaction modes, and another reuses the chart to plan the order of an architecture migration.
How do I work out the complexity of a domain?
The project separates three kinds: essential complexity in designing and maintaining the conceptual model, accidental technical complexity in the current solution, and operational complexity in processes that run outside the software. Further clues cover scale, specialist expertise and how long a newcomer needs to become effective.
Can I use Core Domain Charts for something other than finding core domains?
Yes. The project shows how the same chart can be used to plan the order of a migration from a current architecture to a target architecture, which only needs the y-axis label changed.
What licence do the Core Domain Charts templates use?
The project is recorded as CC-BY-SA-4.0, while the README text describes a Creative Commons Attribution 4.0 International License. The repository contains a LICENCE.md file, so check that file before reusing the templates or images.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/ddd-crew-core-domain-charts)Was this useful?