Over the past couple of years, I have been working with architecture and engineering teams to teach and apply strategic and tactical domain driven design. I will come back with lessons learned in a future post, but this one covers the outcome of these teaching plus consulting engagements for strategic DDD
Remember, strategic DDD is the part that covers the top-level domains, context maps and context mapping patterns. So how do we apply this in practice, who should do it and what does it lead to?
Strategic DDD covers Bounded Contexts, Context Maps, enterprise Domains which are classified into Core, Supporting and Generic domains. We have been teaching this to Enterprise Architecture groups to primarily align to the Business Architecture as a starting point for discovering the top-level domains and bounded-contexts
Who else? In addition to enterprise architects, we teach and work with solution architects, product architects/leads to teach strategic DDD especially context mapping techniques. This is to ensure Continuous Integration, i.e. we want to evolve the view of bounded contexts and relationships between them as they exist in our organisation over time
Between the top-level domain model and then map of contexts, we have a great scaffolding for building our microservices and understanding the communication, constraints and dependencies across teams. After strategic DDD, we apply tactical DDD to each identified context to design and implement the services
Strategic DDD outcomes
As mentioned we build a context map and top-level domain model, however this is done in steps where we start with an eco-system context map, then the enterprise domains, enterprise contexts, enterprise context map and finally develop the team-topology map
We have labelled these artefacts A1 through A5 (yes we get a few “paper-size” jokes) and usually develop these in collaborative software like Miro and formalise it with tools that our clients prefer to align to their standards. We love tools like Context Mapper (see https://contextmapper.org/docs/home/) which helps formalise context maps and version control them
Lets look at these artefacts in detail
A1. Eco-systems map
A2. Top-level Domains, Sub-Domains and Classifications map
A3. Bound-Contexts map
A5. Bounded contexts internal with eco-systems
A5. Team Topology
Summary
Strategic DDD outcomes strongly complement the existing enterprise architecture repository and provide the missing scaffolding and roadmap for delivering top-down business oriented services. This is a key step to building API catalogues and strategic services for internal, public and partner eco-system use cases
Strategic DDD engagements also provide a roadmap for organising teams along the most efficient communication channels for high autonomy and self-service. This view can help leaders organise teams into domain teams, platform teams, enabling teams and ensure the right mix of collaboration and communication is there across teams to accelerate delivery and reduce costs
Alok Mishra 