Finding your core domain
Usually it’s memorable. Because it’s magic.
For “None Of The Above”, someone said it half way through the initial event storming session: “It’s not voting that needs improving, it’s the choices people get. Imagine what would happen if every ballot would always have one additional choice …”
“None Of The Above” is our current example system for the weekly Thursday meetup where we practice developing DDD/CQRS/ES based systems. As always when we embark on a new product, we event stormed the problem, as a step towards identifying the core domain and to plan the project. In Domain Driven Design, the core domain of a system is “The distinctive part of the model, central to the user’s goals, that differentiates the application and makes it valuable.”
We first thought the core domain was secure, auditable, tamper-proof (possibly) blockchain based voting. Not so; this is needed too, but event storming and the resulting discussions among the meetup participants identified the core value proposition: The real value of the system was to give the electorate better choices.
We added two rules.
- No matter what an election or referendum is about, the system always adds one more choice: NONE OF THE ABOVE.
- An election or referendum is null and void if a simple majority of voters chooses none of the above.
The hope is that this will prompt those who put issues to the vote to provide better choices. The experiment whether this will be the case or not requires the system to be adopted by organizations and various levels of government, so we have “driving adoption” as a closely related core competency.
“Giving the electorate better choices”. “Driving adoption”. Two must-haves. Any work we do on the project, technical or otherwise, contributes to these or not, by varying degrees. Project management is simplified because prioritization is clear. People are aligned; the likelihood of anyone working on anything unimportant is reduced, without increasing coordination overhead.
Eventstorming: Our minimum viable product for “None of the above”.
We’ve seen it before.
- Full Moon Plumbing needed to be able to schedule appointments for a plumbing business, but the core domain was “How do I avoid paying for unnecessary overtime?”
- sredder provided businesses with time and cost tracking for Scientific Research and Experimental Development Tax Credit Program applications, but its core domain, the “feature that sold” was the ability to reduce the effort needed to do applications – by retroactively recognising activities as eligible for credits.
These were contrived examples for training purposes, but realistic. We see this a lot when we work with Adaptech customers to help them launch startups and build new products.
Why it’s not useless.
Understanding the true impact of identifying the core domain correctly and using it to streamline delivery is one of the project management lessons we have learned at Adaptech: We exclusively build event sourced systems based on CQRS and DDD principles. Architecting and developing this way leads more naturally to cohesive software made of single-responsibility components than other approaches we’ve seen over the years. As we do little else but DDD/CQRS/ES in our day jobs, constant practice has led to a number of realisations. One of them is the amount of leverage the approach gives us when managing products and projects.
This is why we think about domains, bounded contexts and ubiquitous language a lot. We came to disagree with the sometimes stated assertion that “… Domain-driven Design can come at a relatively high cost”. We find that the opposite is true because DDD, especially the strategic part of DDD, addresses one of the problems endemic in contemporary software development culture:
There is nothing so useless as doing efficiently that which should not be done at all.
— Peter Drucker
Just like realising the benefits from choosing a CQRS/ES based architecture requires a business domain- rather than technical mindset in order to properly establish transactional boundaries and to manage coupling and cohesion, DDD needs certain practices to be firmly established and continuously applied in order to be of value. We find that from a project management perspective, the most important one is constant attention to what contribution a course of action makes to the core domain vs. other areas.
It’s a lot like SQL that way.
Here too the name gives it away. It’s called “Domain Driven Design” for a reason. From a DDD point of view it’s a lot like SQL. Many an awkward side effect prone stored procedure might not have seen the light of day if only they had stopped and exercised the Ubiquitous Language of the Bounded Context at hand. “STRUCTURED QUERY LANGUAGE”. As opposed to “STRUCTURED CREATE, UPDATE, DELETE QUERY LANGUAGE”. My favourite @ericevans0 from #DDDEU 2017: “Give awkward names to awkward concepts.”