NTCoding
commented
4 years ago Thanks for sharing. There are a lot of good ideas here.
What I love the most here is that you also show the importance of "going off-script" - adapting the tools you have available to make the most of the situation you are facing. This to me is what Domain-Driven Design is really about once you get past the basics.
codeliner
I used Core Domain Charts in some discussions with executives lately. (https://twitter.com/prooph_software/status/1291738210259939329)
Since I really like the Wardley Mapping approach of using user needs as an anchor on the map, I tried the same on a Core Domain Chart. I mapped user needs to future positions of sub domains to underline why this would be a good move. I validated the usefulness by using the charts to drive some discussions and I think it makes another good example for this repo here.
Unfortunately, I cannot use the charts and domain for a public example. I try to come up with a good example in the next weeks and create a PR. But if someone has a good one at hand, I'm happy to base my PR on top of it!
But here are screenshots from an anonymized version of such a chart. The chart focuses on one specific sub domain which Team 1 is responsible for. Above the chart you can see a part of a goal map (which I explain below). The goals are mapped to user needs and the user needs are mapped to sub domains on the chart. Only sub domains with touch points to Team 1 are included on the chart and it shows the expected future position of sub domain 1 when goals are reached and user needs met.
To keep the example simple, I'd only include user needs, but remove the goals. Even thought, for our use case the goals are essential:
Some background why I tried to mix user needs into Core Domain Chart:
Our client's c-level management created a "Goal Map". They started from the vision (their purpose), discussed most important user needs they want to address and created a map of cascading goals from long-term -> over mid-term -> to short-term goals along with KPIs for each goal. I really like the approach as a starting point to think about strategic moves that could be taken. The idea is to communicate a rough plan to the teams. But they know that the goals alone don't make a good strategy. The teams are asked to incorporate landscape, climate and own ideas into the plan. This is planned as an iterative process. The Goal Map is not seen as a static artifact but something that is constantly refined. The challenge is now how we can enable the teams to do that. Most of them started learning DDD a few months ago (when we joined the company to help implementing a holistic Event-first Domain Driven Design approach). I think the Core Domain Charts will help us teaching strategic thinking, so I tried to mix goals and user needs with it.