32 lines
1.8 KiB
Markdown
32 lines
1.8 KiB
Markdown
---
|
|
title: Defining Ubiquitous language
|
|
date: 2024-01-24
|
|
permalink: archive/2024/01/24/defining-ubiquitous-language
|
|
snippet: |
|
|
Why should you define the ubiquitous language for a software project? Rob Allen told us during a recent meetup talk.
|
|
tags:
|
|
- software-development
|
|
- php
|
|
- domain-driven-design
|
|
---
|
|
|
|
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.
|