If you want to get started with Strategic DDD to gain deeper insights into your domain and to align your software architecture with your domain, you can use this free Miro template: https://miro.com/miroverse/category/strategy-and-planning/strategic-domain-driven-design-template
If you use the template, your feedback and suggestions would greatly be appreciated. You can find all of the tools on github.com/ddd-crew where you can also leave feedback.
Here’s a quick summary of the tools currently in the toolkit…
Core Domain Charts
Domain-Driven Design uses the terminology core domain to refer to a part of the domain where there is greatest potential for the business to gain an advantage in the market. But for a part of the domain to be core, it also has to be sufficiently complex that deep domain discovery and modelling is worthwhile.
A Core Domain Chart helps you to map out the parts of your architecture as a portfolio and to make strategic decision about where to focus your efforts, where you need to be in the future, and whether to build or buy less strategic parts of the domain.
Architecture Migration Chart
The Architecture Migration Chart is a slightly modified core domain chart which visualises the cost and benefit of migrating each part of your architecture. You might consider using this as a tool for planning a monolith to microservices journey.
It’s also worth noting that changing the tools to suit your scenario is absolutely recommended. If business differentiation and model complexity don’t suit your situation, change them for something that does.
Bounded Context Canvas
Before committing to architectural choices that are hard to change, it is wise to consider essential trade-offs that can have a significant impact later in the project.
The Bounded Context Canvas forces you to answer a series of questions about the design of a single bounded context that you should consider before committing to an architecture, team structure, or writing the code.
The sections on the canvas will help your team to think more closely about the design which will help you to consider alternative options so that you are more likely to choose the best architecture.
Domain Message Flow Modelling
Don’t think you’ve designed an architecture when you have identified the boundaries of your services. It is essential to apply concrete use cases to your model to validate the coupling and potentially uncover hidden coupling.