We’ve encountered a lot of domain-driven design (DDD) sessions over the last fifteen years of our work. It is something few organizations have the time and resources to do, with even fewer who execute them coming out the other side with practical and meaningful change that lives on as part of the enterprise. Even with this reality, DDD still is very important work. Every time we encounter domain-driven design emerge as part of a conversations we tend to encourage everyone to do more thinking about how we can get everyone more aligned within a domain, but doing it in motion without disrupting existing work. This approach cknowledges that it is unlikely we will ever have the time and bandwidth and time for properly implementing full blown domain-driven design-—choosing instead tofocus on micro versions of the same work, but doing it incrementally in this moment with the following characteristics.
- In Motion - Tagging, categorizing, and adding semantics to each artifact we encounter along the way.
- No Perfect State - Knowing there is never a perfect state of domain, just regular housekeeping.
- Taming the Sprawl - Incrementally taming parts of the API sprawl that we encounter, knowing we can’t tame it all.
- Bringing Some Order - Collectively bring order within the domain we operate and matters most to our work.
- Addressing Change - Regularly discussing change and how the words we use to describe things have evolved.
- Common Vocabulary - Publish that glossary and regularly refine, socialize, and apply words and phrases to Apis.
Getting everyone in the same room for an extended period of time to define and negotiate each domain that exists within an enterprise makes a lot of sense right up until the point it comes up against the scheduling, costs, and loss of work it takes to get everyone in the same room. Even if you can achieve that, the second challenge is taking all of the domain-driven design work after a successful session and assimilating it back into regular daily operations. It makes more sense to just take a handful of domains, the tags and vocabulary for that domain, and devote a couple hours a week to discussing, organizing, and applying tags to APIs.json, OpenAPI, JSON Schema, and Spectral or Vacuum rules, then report, iterate, and adjust your approach over time until you achieve desired results–perpetually designing your domain as it evolves.
