# ddd-crew/ddd-starter-modelling-process: an eight-step guide for teams new to Domain-Driven Design > The ddd-crew starter modelling process is a documented, iterative sequence of eight collaborative modelling steps aimed at people who are new to DDD and do not know where to begin. It is a guide and a set of canvases, not a library you install into a codebase. **ddd-crew/ddd-starter-modelling-process** — If you're new to DDD and not sure where to start, this process will guide you step-by-step - Repository: https://github.com/ddd-crew/ddd-starter-modelling-process - Stars: 6,041 · Forks: 568 - Language: Unknown - License: CC-BY-SA-4.0 - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/ddd-crew-ddd-starter-modelling-process ## What the ddd-crew starter modelling process is for, and who should pick it up Domain-Driven Design has a reputation problem that has nothing to do with its ideas. The vocabulary is large, the sources are dense, and a team facing a real deadline has to decide where to begin. The ddd-crew starter modelling process is a direct answer to that: the README says it exists so you can "focus on your business challenges and not be overwhelmed by learning DDD at the same time." The stated audience is narrow and honest. The README calls the process one "for beginners" and lists eight situations where it applies: kicking off a greenfield project, beginning a brownfield migration, starting a major programme of work, exploring a domain for new learning opportunities, assessing how well a current system aligns to the domain and business model, reorganising teams, and simply practising or teaching DDD. That list is the useful part. It tells you this is a facilitation and discovery aid rather than a development methodology. If your team already has a modelling habit and a shared vocabulary, the process will feel like scaffolding around work you already do. If your team has never drawn a bounded context on a wall together, the scaffolding is the point. ## The eight steps: Understand, Discover, Decompose, Strategize, Connect, Organise, Define, Code The process has eight named steps, and the README's own table of contents is the clearest statement of the mechanism: Understand, Discover, Decompose, Strategize, Connect, Organise, Define, Code. Each step in the documentation carries a Tools subsection and a Who to Involve subsection. That pairing is the actual design: a step is defined by the artefacts you produce and the people who need to be in the room, not by a deliverable handed to the next stage. The README's diagram, stored at resources/ddd-crew-modeling-process--cirlces-feed-each-other.svg, shows the steps as circles that feed each other rather than a pipeline. The documentation repeats the point in prose: on a real project you will be jumping back and forth between the steps, and the process itself is described as "not a linear sequence of steps that you should standardise as a best practice." So the architecture is a loop with eight labelled regions. That matters for how you run it. A team that treats the eight steps as a stage gate will produce eight sets of artefacts and no model. A team that treats them as a menu of lenses, applied until the model stops changing, is using the document the way its authors describe. ## Running your first iteration: what to read and what to prepare There is nothing to install. The repository is documentation: the top level holds README.md, LICENCE.md, _config.yml for the published site, plus case-studies/, resources/ and translations/ directories. There is no package manifest, no build step and no CLI, so the first practical move is to read the README on the default branch and pick your entry point. If you want to check what the repository contains before a workshop, cloning it is enough: ```bash git clone https://github.com/ddd-crew/ddd-starter-modelling-process.git cd ddd-starter-modelling-process ls ``` The listing should show README.md, LICENCE.md, _config.yml, case-studies/, resources/ and translations/. The resources/ directory is where the process diagram lives, and translations/ holds the translated versions of the guide. For a first real use, the README points at a companion exercise: colleagues at SAP published a DDD Kata, described as a way to "educate teams, how to apply the DDD Modelling Process in your team." Based on a set of requirements, the kata lets a team try how EventStorming, Domain Message Flow, Bounded Context Canvas and Aggregate Canvas work together and validate design decisions. That is a lower-risk first run than pointing the process at production work. ```bash git clone https://github.com/SAP/curated-resources-for-domain-driven-design.git cd curated-resources-for-domain-driven-design ``` After cloning, the kata file is ddd-kata.md on that repository's main branch. Read it before the session, not during it. ## Adapting the order: the entry points the README actually sanctions The most interesting section of the documentation is the one on adapting the process, because it undercuts the numbered steps it just described. Six adaptations are listed. Start with collaborative modelling if you want the whole team involved immediately, on the argument that modelling a domain they already know is more comfortable than discussing business models and strategy they do not. Start by assessing the IT landscape if it is better to visualise the existing architecture first: the README suggests beginning at step 5 and mapping the strategic portfolio to see the major constraints you will face. Code before confirming architecture and team boundaries is listed as valid on some projects. Repeating steps 2 (Discover) through 6 (Organise) before moving to 7 (Define) is another. Organising teams before designing contexts is a fifth. Blending definition and coding is the sixth. Read together, these are not variations on a theme. They are admissions that the sequence is a teaching device. The README says as much: this linear process "is not a realistic process. It's just a starting point to reduce cognitive load until you are confident with DDD." That is unusually direct for a methodology document, and it is the sentence to quote at anyone who wants to turn the eight steps into a project plan. ## Where the process breaks down, and when it is the wrong tool The clearest limitation is self-declared. A beginner-facing, linear-looking guide invites exactly the behaviour its authors warn against: standardising it. If your organisation has a stage-gate culture, the eight steps will be read as eight gates, and the documentation's own caveats will be treated as fine print. Nothing in the repository enforces iteration. The second limitation is that the process produces artefacts, not decisions. The README's Tools subsections point at canvases and modelling formats, and the kata exercise shows EventStorming, Domain Message Flow, Bounded Context Canvas and Aggregate Canvas working together. Whether the resulting boundaries are right is a judgement the guide cannot make for you. A team that finishes an iteration and asks "are we done?" will not find an answer here. The third is audience. The README states the process is for beginners. A team with several years of DDD practice will find the step definitions and the Who to Involve prompts remedial. The honest use case for an experienced team is teaching, or a deliberate reset after a reorganisation. Finally, there is no versioning signal to rely on. The repository lists no releases, and the last push to the default branch was on 2026-08-23. That is recent enough that the guide is not stale, but there is no changelog to diff between the version you read and the version your colleague read. ## How it differs from EventStorming alone, and from a framework like Team Topologies The obvious alternative is to run EventStorming by itself. EventStorming is a single collaborative modelling format; the starter modelling process wraps it inside a larger sequence, where Discover has its own tools and Who to Involve, and where the output feeds Decompose and Strategize. Choosing EventStorming alone gets you a wall of events and a faster start. Choosing the starter process gets you a place to put those events and a reason to involve people outside the room. A second comparison is Team Topologies, which also concerns team boundaries and coupling. The difference in approach is the direction of travel. Team Topologies reasons from team interaction patterns toward architecture; the starter modelling process reasons from the domain model outward, with Organise as step 6, after Understand, Discover, Decompose, Strategize and Connect. The README makes the dependency explicit in its reorganisation scenario: a loosely-coupled architecture must be aligned to coupling in the domain, and the process is meant to help you design both together. It also offers the reverse adaptation, organising teams before designing contexts, for teams that need to move in the other direction. Neither alternative is a drop-in replacement. The starter process is the only one of the three that assumes you are new and sequences the work accordingly. ## Licence, maintenance and the cost of keeping up The licence is CC-BY-SA-4.0, and the repository carries a LICENCE.md file at the top level. For a documentation project that is a meaningful choice: the ShareAlike condition means adaptations you distribute carry the same licence, and the Attribution condition means contributors must be credited. If you plan to fork the guide into an internal handbook, read LICENCE.md rather than assuming the terms from the identifier. This is a description of the file, not legal advice. Upgrade cost is low in the usual sense and non-zero in an unusual one. There is no dependency to bump and no API to break. The cost is re-reading: the README is long, with nested navigation, and the adaptations section changes what the steps mean. A team that adopted the guide a year ago and pinned a printed copy has a document that no longer matches the repository. The maintenance signal is the last push on 2026-08-23 to the main branch, and the repository is not archived. No releases are listed, so there is no version number to track. Translations live in the translations/ directory and case-studies/ collects published examples; both are worth checking before you write your own internal guidance, since someone may already have documented your situation. ## Conclusion Adopt it if your team is new to Domain-Driven Design and needs a shared, low-cognitive-load sequence for the first few modelling iterations, especially on a greenfield kickoff or before a legacy migration. Do not adopt it as a standardised delivery process: the README states plainly that the linear order is not realistic and that the steps feed each other. Before you start, decide which step you will begin at, because the README lists several valid entry points (collaborative modelling, assessing the IT landscape, or coding before confirming architecture and team boundaries), and check the LICENCE.md file in the repository for the exact terms of CC-BY-SA-4.0. ## FAQ ### What does DDD mean in programming? Domain-Driven Design is the practice the starter modelling process teaches: designing a software system around an organisation's business model and domain rather than around technical layers. The README describes the process as covering everything from orienting around that business model to coding a domain model. ### How does the ddd-crew starter modelling process work? It is an eight-step sequence (Understand, Discover, Decompose, Strategize, Connect, Organise, Define, Code), where each step documents its own tools and the people to involve. The README stresses that the steps feed each other and that on a real project you jump back and forth between them. ### Is there a PDF or slide deck of the ddd-crew starter modelling process? The repository contains README.md, LICENCE.md, _config.yml and the case-studies/, resources/ and translations/ directories. No PDF or presentation file is listed among those top-level entries. ### Can I use the ddd-crew starter modelling process on an existing legacy system? Yes. The README lists beginning a brownfield migration as a scenario, stating that a few iterations can uncover the information needed to create a vision for your target architecture. It also suggests starting at step 5 and mapping your strategic portfolio to see the major constraints first. ### Do I have to follow the eight steps in order? No. The README states the process is not a linear sequence to standardise as best practice, and lists six ways to adapt it, including starting with collaborative modelling, assessing the IT landscape first, or coding before confirming architecture and team boundaries. ### What licence does the ddd-crew starter modelling process use? The repository is licensed under CC-BY-SA-4.0 and carries a LICENCE.md file at the top level. Because it is a documentation project, that licence applies to the written guide rather than to software you would ship. ## Sources - [ddd-crew/ddd-starter-modelling-process on GitHub](https://github.com/ddd-crew/ddd-starter-modelling-process) - [Issues](https://github.com/ddd-crew/ddd-starter-modelling-process/issues) - [License: CC-BY-SA-4.0](https://github.com/ddd-crew/ddd-starter-modelling-process/blob/main/LICENSE) - [README](https://github.com/ddd-crew/ddd-starter-modelling-process/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ddd-crew-ddd-starter-modelling-process