Dear Junior
Among programmers it is not uncommon to get into discussions on naming of variable, methods, classes etc. A pretty common way to resolve these discussions is to say “let’s ask the domain expert”. Even though I encourage communication across disciplines, there is a sub-tone that alarms me: the sub-tone of “checking the answer”, like if the proper domain model was in the head of the domain expert, and the task of the programmers is to uncover it and write it down in code. I think this surfaces two different misconceptions about domain modelling in general as understood by domain driven design.
The first misconception is the kind of expertise the domain expert has. He or she might very well be an expert stock trader, online campaign marketer, or transportation router – but that expertise is about performing tasks within the domain, not necessarily to think and reason about the domain. This is analogous to the difference between doing a left turn on a bike, or to explain how to make a left turn.
To put it another way, most domain experts are not consciously aware of their expertise. Of course, they probably are aware that they are experts – but they are not aware of what makes them experts – the same way most people don’t know why they can make a left turn. So, asking them to give a model will probably just give you a “first order approximation” or a naïve model that will hold for “typical” cases – but will probably break down when things are getting a little bit trickier. Key phrase for spotting this is: “Oh, well, of course, if the shipping organisation [whatever] is actually the ordering organisation [whatever], then there of course shall be no transit-through fee [obviously not …]”.
At one project I entered there where some severe confusion on the tech side of what went into a “notification” as opposed to an “announcement”. Different tech people had talked to the domain experts and this had resulted in inconsistent requirements. The approach to “ask the expert” had been used several times, but the confusion had only gotten worse. After a while I realised that the domain experts where not aware of the difference themselves – to them the two nouns where more or less synonyms and used interchangeably, because the precise meaning was obvious by context. They where perfectly able to handle any “notification” or “announcement” but could not verbalise a precise distinction between the two – that took some serious domain modelling to work out.
The domain experts are experts in the domain, not experts in modelling the domain. Domain modelling is a separate skill set, and that is why they need you to help them out. They simply cannot do it themselves. So, the proper way is not to go “ask the domain expert”, it is to go “work with the domain expert” to see what domain you can come up with in mutual cooperation.
Naturally there are exceptions. If a domain expert has spent considerable time and effort thinking about the domain, they might well have reached a knowledge depth that enables them to model the domain. To spot that kind of domain expert, keep your eyes open for signs that he or she has spend explicit efforts on verbalising the domain. The expert might have e g worked as an instructor in the field, given presentation for larger auditoriums such as at conferences, or might have written articles or books on the subject. If you spot such an expert; grab, hold on, and do not let go – this is a gold mine.
The second misconception in “model in expert’s head” is even more fundamental. Central to domain driven design is the attitude that models are evaluated by their usability (as in “fit for purpose”). A model could in a philosophical meaning be “true” or it might “cover a lot of the world” – but those properties are simply uninteresting. What counts is if the model can handle the cases you have at hand, and doing so in a simple way.
In other words, for the set of behaviour (“stories”, “use cases”) we have, there are an infinite number of models. Of those, none is “the right”. On the contrary, there might well be an innumerable number of models that all give the correct behaviour, and the way to discriminate between those is to find those that seem simple, in other words using Occam’s Razor.
It is logically possible that there might be several domain models that all fulfil the correct behaviour, and where none of them can be said to be simpler that another – they are all simple, but in different and incomparable ways. Then, any of these will do as a good domain model. So it is not logically necessary to search in the head of the expert. Instead let us investigate a lot of options (possible models) and select from those.
This also sets the tone of how I prefer to work with the domain experts. Instead of focusing on one model, I try to come up with several optional models that I see would fulfil the requirements, and then ask the domain expert for gut feeling. Best way to do this is a few people in a small room with a whiteboard with a lot of “generate and test”, i e find up a few models, ask for opinions, try them out on some scenarios, watch the reaction of the expert, throw away those models that where less promising, come up with some variants of those we kept, etc.
To know how long to continue this evolutionary modelling, Eric Evans has a rule of thumb I like: “keep modelling until you have created three really bad ideas”. As long as you just create good models you are probably not creative enough. It is the generation of bad ideas that prove that you have been pushing the borders.
In conclusion: I do not think there is a domain model in the head of the expert. Firstly, it is improbable because the domain experts are in general not aware of their expertise. Secondly they are not skilled modellers (their expertise is elsewhere), so the model you get by asking is often very naïve and incomplete. Thirdly, even if there would be a model there, that model has no advantage over any of the other possible models that fulfils the same purpose.
So, the way to communicate with domain experts to create a domain model is not to “ask them” it is to “work with them”.
Yours
Dan
ps When asking if someone "knows" something, if you then require them to understand the subject in depth, then most people do not know how to ride a bike.