From d82ad98e4e7ef8aa86ef7dc1117da2360f2a9166 Mon Sep 17 00:00:00 2001 From: Oliver Davies Date: Thu, 25 Jan 2024 00:54:34 +0000 Subject: [PATCH] Add daily email for 2024-01-24 Defining Ubiquitous language --- source/_daily_emails/2024-01-24.md | 31 ++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 source/_daily_emails/2024-01-24.md diff --git a/source/_daily_emails/2024-01-24.md b/source/_daily_emails/2024-01-24.md new file mode 100644 index 000000000..3b02e9e94 --- /dev/null +++ b/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.