0

I am curious about your approaches/heuristics to the exploration of domain (subdomain, bounded context) during DDD modeling session.
As everyone knows most of programmers tend to be perfectionists (especially in the places where it is definitely not needed). Our industry has learned that it is extremely important to produce solutions good enough rather then perfect, otherwise the cost of the development is not balanced with the effect. Though the term good enough is ambiguous, dependent on the context, we seems to established guidelines which lead us in good direction (in most cases) - the simplest code which fulfill acceptance criteria, using design patterns, test driven development to name a few.
Having this in mind, what is your approach when it comes to exploration of domain? When you know you should stop exploring and jump into next area/start coding? Of course each domain session you will know your domain better, explored deeper - my question is about single session. Is it based on domain expert opinion, length of modeling session or maybe some arbitrary goals set by customer? Or maybe something totally different?

4
  • 2
    Long enough to know what you need to do to code up your solution. Jan 4 '18 at 2:11
  • 1
    @RobertHarvey How do you know that "you know what you need to do"? Customer comes to you with user story - is it enough for you and you start to code up the solution? Why then you need modeling session at all. My question was regarding situation when you explore domain with domain expert to reach all dependencies. And of course "all" is sometimes utopy (because it is always something more to find). That is the clue of my question. Looking forward for your answer to that topic. Jan 4 '18 at 8:48
  • 1
    There isn't any litmus test that you can apply. You're done with the design when the design embodies all of your necessary design elements. Note that you don't need a complete design to start coding... you just need enough design to start coding that part of the application you've designed. And you really don't even need that; all you really need are the interface boundaries and some requirements. Jan 4 '18 at 16:49
  • It is kind of like the two forms of Zeno's paradox: can't get all the way there because you have to go half-way first, and can't even get started because to go half-way, first have to go quarter-way, etc. This is why programming is impossible.
    – user251748
    Jan 4 '18 at 16:56
2

Exploring a domain is an ongoing, iterative process. Eric Evans in the DDD book has this notion of breakthrough, an epiphany that can come at any point down the domain modelling process. Sometimes a team will code a feature only to discover later that they lacked one hidden genius abstraction that makes the whole thing easier to code and comprehend.

My advice is to explore with domain experts enough to attain a shared domain model, a glossary and a succinct definition of the use cases to be built, but not think you're going to get it right the first time.

How much scope to cover exactly in one modelling session can conveniently follow lines in the methodologies you're using - DDD Bounded Contexts, microservices, Agile increments/sprint goals, DevOps shippable units, etc. Starting with one big picture model of the whole domain and its subdomains is often helpful - it can usually be sketched out in one meeting and updated along the way. You can also have a look at Event Storming for good tips about the scope and organization of design sessions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.