Unlocking the power of Ubiquitous Language
Last updated: April 03, 2024 Read in fullscreen view
Recommended for you
- 01 Aug 2024
The Standish Group report 83.9% of IT projects partially or completely fail 150/1772 - 13 Apr 2024 Lessons on Teamwork and Leadership from Chinese story book "Journey to the West" 41/949
- 02 Nov 2021 What is Terms of Reference (ToR)? 23/1466
- 03 Apr 2022 Microsoft Solutions Framework (MSF) 12/1157
- 18 Dec 2023 The Cone of Uncertainty in Scrum & Requirement Definition 8/643
- 18 Oct 2021 Key Elements to Ramping Up a Large Team 7/1108
- 11 Jul 2022 Cost benefit analysis for software development 4/662
- 20 Jul 2022 Software Myths and Realities 4/797
- 07 Jul 2022 Managing Project Execution Terms 3/379
- 10 Apr 2024 The Parking Lot Method: Unlocking a Simple Secret to Supercharge Your Productivity 3/403
- 26 Sep 2024 Successful Project Management Techniques You Need to Look Out For 2/368
- 05 Jun 2023 Fractional, Part-Time (virtual) or Interim CTO: Who Will Cover Your Business Needs? 2/109
- 02 May 2022 What Is RAID in Project Management? (With Pros and Cons) 2/734
- 24 Nov 2023 The project management paradox: Achieving MORE by doing LESS 2/193
- 14 Jun 2022 Example and Excel template of a RACI chart in Software Development 2/707
- 12 Aug 2022 What is End-to-end project management? 2/382
- 15 May 2022 20 Common Mistakes Made by New or Inexperienced Project Managers 2/247
- 22 May 2022 What are common mistakes that new or inexperienced managers make? 1/243
- 27 Jan 2020 Should a project manager push developers to work more hours due to mistakes of manager schedule setting? 1/412
- 07 Dec 2023 12 project management myths to avoid 1/167
- 01 Mar 2024 10 Project Management Myths 1/120
- 01 Aug 2022 Is planning "set it and forget it" or "set it and check it"? /264
- 02 Jun 2024 Reviving Ancient Wisdom: The Spiritual Side of Project Management /204
- 30 Nov 2023 Project Managers, Focus on Outcomes — Not Deliverables /143
- 02 Nov 2022 Difference between Change Management and Project Management /216
- 14 Feb 2024 Early BA Engagement: “Earning” Pre-Project Work /149
- 23 Jun 2024 Best Practices for Managing Project Escalations /183
- 21 Jun 2024 Dead Horses and the Escalation of Commitment /123
- 17 Oct 2021 Does Fast Tracking increase project cost? /348
- 13 Jan 2020 Quiz: Test your understanding project cost management /568
- 02 Dec 2021 3 Ways to Avoid Scope Creep in IT Consulting /192
- 06 Jun 2022 Change Management at the Project Level /292
- 09 May 2022 Build one to throw away vs Second-system effect: What are differences? /297
- 10 May 2022 Levels of Teamwork /180
- 03 Jan 2023 Organizing your agile teams? Think about M.A.T (Mastery, Autonomy, Purpose) /333
Ubiquitous Language (UL) is a concept introduced by Eric Evans in Domain Driven Design, which involves creating a common language between developers, stakeholders, and domain experts, to communicate and understand the business domain (i.e. finance, insurance etc). This common language ensures that everyone speaks in terms (usually come with Project Glossary) consistent with the domain model, eliminating ambiguities and misunderstandings.
By using the model-based language pervasively and not being satisfied until it flows, we approach a model that is complete and comprehensible, made up of simple elements that combine to express complex ideas.-- Eric Evans
Challenges for high complex software projects
- Lack of a common language can lead to wrong Domain Models.
- Team members use terms differently without realizing it due to lack of a common language.
- Technical team disregards domain experts' participation.
- Technical team creates data models that are not understood by domain experts.
The primary goal of the UL is avoiding misunderstandings and assumptions on both ends—stakeholders and development teams. The importance of using the UL in conversations with domain experts and ensuring it evolves as the team's understanding of the domain grows.
Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding; developers should watch for ambiguity or inconsistency that will trip up design.-- Eric Evans
To develop a UL, open discussions, analysis of existing documents, dictionaries, and standards are essential. Methods include drawing domains on a whiteboard, creating glossaries, using Event Storming, Event-driven Process Chain (EPC), and reviewing and updating generated code. Code should express the UL, and developers should abandon outdated documentation.
To produce a clear UL you will have to understand more of the business.
- UL is a shared language within a limited context, identifying terms and concepts of the business domain.
- UL is not a business language imposed by domain experts.
- UL is not a language used in industries.
- UL evolves over time, it is not defined entirely in a single meeting.
- For developers it is much easier to communicate with the business team, as they are familiar with the terms too.
- UL eliminates inaccuracies and contradictions from domain experts (domain expertise, functional expertise).
Domain Expertise: Domain expertise is the knowledge that enables you to excel in a specific field or industry. It isn't just about knowing the technical aspects, but also understanding the goals, products, market needs (not customer's wants), industry, niche, problems, pain points, challenges and gain points of your customers. With domain expertise, you can help your customers achieve their desired and realistic outcomes.
UL is modeled within a limited context, ensuring no ambiguity in terms and concepts of the business domain. It is not a business language imposed by domain experts or used in industries. It evolves over time and rejects concepts not part of the UL. Common problems to avoid include lack of a common language, team members using terms differently without realizing it, communication without using UL, and technical teams disregarding domain experts' participation.
UL - shared language for all participants (internal members, external members)
When preparing Business Cases, Business Blueprints, developing ideas and implementing Software Solutions, software developers can choose to modernise the legacy systems using the Like-4-Like approach without having to reinvent the wheel. A well-known technique for doing this is domain-driven design, or DDD. By using a common language (ubiquitous language), a design (or “domain model” is created) and defining themes, the subjects (entities) are described.
Benefits of UL
If everyone uses the same ubiquitous language and terminology, it becomes easier to keep track of the requirements for implementation. Terminology matters and using a set of ubiquitous terms can make or break a development team from understanding what is really needed to deliver value to users.
UL offers several advantages, such as:
- Improved communication and collaboration among stakeholders.
- Consistent terminology and understanding across the project.
- Fewer misunderstandings and errors in implementation.
- Greater alignment between the domain model and the software implementation.
Limitations of UL
UL is not always a silver bullet approach or best-fit solution for all projects. Think about disadvantages as following:
- UL requires a domain expert to understand the software's application domain (put the right features into the domain context).
- Developers and business teams need to understand the domain thoroughly, which can be time-consuming.
- Domain experts should object to terms or structures that don't convey domain understanding.
- Developers should be vigilant for ambiguity or inconsistencies that could hinder design.
- UL may create more work than necessary for simple domains like job applications.
- For highly technical projects, UL is not recommended.
Key Takeaways
As software developers, it is crucial to understand that clients are not interested in the software's language or patterns, but in its ability to solve problems within their business domain. This is where the Ubiquitous Language (UL) comes in. UL is a vocabulary of domain-specific terms shared by all parties involved in a project, translating the business domain to the code domain. UL includes nouns, verbs, adjectives, idiomatic expressions, and adverbs. It is not static and is continuously updated and refined as the project matures.
Ubiquitous Language is a common and rigorous language used between developers and users to mitigate misunderstandings and bad assumptions. It should be used in all forms of written and spoken communication, becoming the universal language of the business. It is advisable to add an "APPENDIX x, Ubiquitous Language" to your specification document or client's collaboration tool, such as their wiki or intranet. By understanding and utilizing UL, developers can better communicate with their clients and ensure a smoother transition from the business domain to the code domain.
Explore more on these topics
26072024043639_thumb.jpg){kind=spacer}
Guest Blogging: The Definitive Guide
Top Trending Topics
Share This
Link copied!
Recently Updated News