Add daily email for 2024-01-24

Defining Ubiquitous language

source/_daily_emails/2024-01-24.md

@@ -0,0 +1,31 @@
+---
+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.