Inventing domain language
One of the main ideas of Domain Driven Design is building a shared domain language called ubiquitous language. Typically you do it by listening to the domain experts and capturing the language they use. Domain expert is seen as some well seasoned veteran who has years of experience working in the business.
What if you don’t have access to such experts? There can be many reasons. For example, your product does not clearly map to any single preexisting business model. How to build domain language in such a scenario? Is it even valuable?
The technical language
Some kind of specialised language always emerges inside the team/organisation. However, when it evolves by itself it tends to be more technical and coupled to existing UI or other implementation details.
When we built the money transfer product at (Transfer)Wise we wanted to show our customers a quote of our fees, delivery estimate and how much they save compared to using a bank’s currency exchange. Originally we called this Calculation response. This was based on our UI that had a widget we called Currency calculator. The object that captured the user’s intention to transfer money was called Request. These names were used in our codebase, when we talked about the product within the engineering team but also in discussions with our support and operations teams.
Why is growing domain language valuable?
Why is it valuable to nurture the domain vocabulary consciously instead of letting it grow its natural course?
The everyday language we use impacts how we think about the world around us. Similarly, a well chosen language in a software system can either inspire and expand your thinking or it can constrain you. Having domain language that contains references to your current UI implementation can make it harder to explore new kinds of presentation options or build more generic APIs.
This is where DDD and it’s idea of listening to domain experts comes in handy. However, even if you have such domain experts available, just listening is not enough. It is the job of the development team to make this language more concise where it is superfluous and expand it where needed.
Using another domain as a metaphor
One idea introduced by Kent Beck with XP is the system metaphor. It’s about using the analogy of some other commonly known domain and applying it to simplify thinking about the problem at hand. In our case we realised that we can borrow many concepts from the retail domain.
When retail is about selling physical goods then in our case the product was transferring money from our customer in one currency to the recipient in another currency.
This helped us to build a richer domain language. Instead of having a Calculation request/response we started talking about providing a Quote. When this Quote was accepted it was used to set up an order to make a Transfer. During this process we moved from ordering subdomain into fulfillment where the focus was delivering money to the recipient.
Summary
Well nurtured domain language simplifies communication within the organisation and with customers (especially in case of APIs). It also helps to expand the way how the product/system can be used to fulfil future use cases.
Even when you are not working with domain experts in a classical sense it is still a good idea to keep your domain language decoupled from technical details.
