How to involve a domain expert into modeling — visual and linguistic DDD techniques
It is a review of JDD 2014 talk by Sławomir Sobótka originally published at Future Processing technical blog along with other talks reviews. The video recording (in Polish) is available on youtube.
This talk was presented in Polish, its original title is „Jak wciągnąć eksperta domenowego w wir modelowania — wizualne i lingwistyczne techniki DDD”. It used linguistic techniques that are typical for Polish language. Nonetheless, I’ll try to get the gist out of it, because approach and way of thinking is applicable to any natural language.
The most important takeaway from this lecture for me was: naming is very powerful, because it affects our thinking. Also naming things is the most difficult thing in computer science, a famous quote by Phil Karlton. In order to avoid running into rabbit hole with putting labels on objects we should avoid putting names on classes as long as we can. Sławek suggested to use gibberish game for naming, or just put a „Blah” name first. From practical perspective it helps to avoid generic names like manager, resource and such.
Object Oriented Programming is about message passing, events and signals — not sticking together procedures and data structures. Hence Object Oriented Design should focus on mentioned behaviours and system events, which will operate on objects. After we’ve got actions and relevant objects it’s way easier to name classes. The proper order of Object Oriented Analysis is then as follows:
- Behaviour, action, operation (technically: method)
- What does it do?
- Behaviour rules (technically: method implementation)
- How does it do it?
- Data that is processed (technically: attributes)
- What is the thing?
- Name (technically: class name)
- What it is?
Above rules help to get a common ground with domain expert while designing domain model of the system. The goal is to have names in code that are understandable to business. It’s not only about class names, but also methods and even their implementation. Take a look at the following piece of code — it reads almost like a prose:
Try a trick with that piece of code: strip all Java-specific language constructs from it and give it to a non-technical person to read. If they grasp it, then it’s good code. Such technique is called „IVONA test„, a term coined by Michał Bartyzel. You can even use „IVONA text-to-speech software to try it yourself.
Another protip for object analysis with domain expert is to note down everything expert says. Not only gives us the record, but also lets find out illogical statements and missing pieces of the puzzle — things software engineers are pretty good at. Furthermore, it’s a base for linguistic analysis, that translated to object analysis quite nice. Here’s how parts of sentence translate into programming language constructs:
- To reservation add product, given quantity
- Subject.predicate(object)
- Object.method(parameter)
- reservation.add(product, quantity)
During the talk the speaker touched on many other aspects of Domain Driven Design. Many of them deserve their own blog posts, so let me just list them:
- Whirlpool Model Exploration — knowledge flow between expert and modeler
- how different people see system (and objects in it) differently
- why estimations based on GUI mockups are bad idea
- why process does not tell you everything
- visualization techniques
Overall the lecture was packed with knowledge from different domains (linguistics, visualization, knowledge exploration, cognitive science, object oriented design, DDD) with great jokes incorporated at the right moment. Even though talk was light in terms of perception and entertaining. It is definitely worth watching if you have got a chance. Thank you Sławek.
