Conversations with domain experts and the language used are central in Domain-Driven Design (DDD), but often this is hard because we don’t speak the same language, explained Cyrille Martraire in his presentation at the Domain-Driven Design Europe conference earlier this year when sharing his experiences working with domain experts in DDD-driven environments.
Martraire, founder of the Paris Software Craftsmanship Community and co-founder of arolla, claims that to successfully meet with domain experts you first have to teach yourself some domain knowledge. Do your homework and create some prior knowledge, for example by reading books or finding information on Internet.
For Martraire, showing some knowledge of the domain is a way of establishing credibility and improving the communication with the experts. Three simple ways of doing this are:
- Show your genuine curiosity and the knowledge you have
- Ask better questions and improve them over time
- Challenge, but respectfully
Martraire notes the importance of paying close attention to the words, refraining from translations or other distortions. He notes that active listening is hard and therefore has created a technique he calls Word Safari where he notes all the new words from the domain expert. He can then check if they are new concepts or synonyms. He emphasizes that this is not just a simple trick- attention to the language used is essential in DDD.
One technique Martraire has found useful is navigating the conversation. You can navigate upwards to a more abstract level to summarize and find the intent. The key question here is why, usually asked more than once. You can also navigate downwards to more concrete details, and in this case examples are important for finding misunderstandings. One way of working with examples is using Behaviour-Driven Development (BDD) to describe concrete examples of behaviour together with the experts. The third way of navigating is going sideways to explore the breadth of the domain. Sometimes this can expose areas not discussed at all.
One rule Martraire believes to be extra important is to make it clear to the domain experts that they are safe with you and that you have no plan to steal their job. One consequence of this is that you always ask for validation of everything; in the end there has to be a mutual understanding of the domain.
This can all look nice and easy but in Martraire’s experience it can sometimes be hard to find great domain experts. As he claims:
The worst domain expert is the one whose expertise was built from the intricacies of the existing system.
He also reveals that his experience might be somewhat biased because he usually chooses projects based on their DDD potential and the collaborative mindset of the people involved.
Next year’s Domain-Driven Design Europe conference is scheduled for late January 2017.