A key takeaway from Rob Allen's Domain-Driven Design talk was defining ubiquitous language and avoiding the phrase "That's not what I meant".
Even a simple table or glossary that lists business and domain-specific terms and their agreed meaning is very helpful to ensure everyone in the discussion is on the same page and means the same thing.
Rob's example was using the words "policy" and "risk" when dealing with insurance clients.
A common issue I've seen is where people are referred to as customers by the business and users within the software.
Ideally, these should be consistent, and the code should match the business terminology.
This can be complicated further by different areas of the business, such as a marketing team that may refer to people as subscribers.
Without the ubiquitous language being defined, the requirements are more likely to be misunderstood and the wrong solution delivered, resulting in "that's not what I meant.".
This then means the work needs to be re-done and delayed, which can be expensive and time-consuming.
Another approach is to work in small batches, which is something I've written about before, and getting feedback from customers as early and often as possible so, if there is a misunderstanding, the minimum amount of time has been spent before it's realised and rectified.
Rob, of course, covered a lot more about DDD in his talk, and I'm looking forward to re-watching it once the video from the meetup is released.
P.S. Need help or want another pair of eyes on your code? Book a 1-on-1 consulting call or an online pair programming session with a 100% money-back guarantee.
Top comments (0)