Ubiquitous Language – Accuracy Vs. Relevance

This post is third in a series on Ubiquitous Language and Domain-Driven Design.

Part 1 – Communication Vs. Jargon

Part 2 – Every Misunderstanding, a Bug

In part one of this series, I argue that the prevalence of jargon in the problem and solution spaces necessitates a clear and contextualized language that all project stakeholders actively use. In part two, I discuss the most common side-effect of misunderstandings in software projects: the defect.

Photo courtesy of shaman-j

Perhaps its odd that I’m spending so much time talking about and making the case for a ubiquitous language, especially since the concept receives little intensive treatment in DDD circles compared to the classic building-block patterns and new innovations, such as CQRS and Event Sourcing. A simple Google search on DDD-related blogs, or a quick perusal of the DDD Yahoo! Group will reveal that most of the time and effort spent reasoning about the art of Domain-Driven Design is spent on technical patterns and implementation strategies, as opposed to the “softer side” of DDD: language, context and strategic design patterns.

I recognize that my multi-post treatment of Ubiquitous Language may come off as a “Duh” moment for an experienced DDD practitioner. After all, Evans’ treatment of the idea of language and its importance in the creation of software-intensive systems is concise and well-reasoned, leaving out little in the way of justification. And while my goal is partly to reinforce that justification with some of my own, lesser reasoning on the subject, I also wish to illuminate some of the differences between the language of domain experts and development teams so as to underscore those areas most critical to unify into the new, shared language that Evans proposes. These are areas not covered explicitly by Evans that, in my opinion, can aid the DDD practitioner in the actual hands-on creation of a Ubiquitous Language; something not given in-depth treatment in the book.

To be completely transparent, I believe that Ubiquitous Language holds value even where a project is too simple to necessitate a DDD-style approach.

As such, I discuss communication and jargon in part one to underscore the need to confront domain jargon head on, either eliminating it in favor of alternate terminology, or formally bringing it into the new language. My second post on software defects serves to reinforce the idea that a shared language favors clarity and, as such, tends to result in software that does exactly what it was meant to do.

In this post, I’d like to discuss accuracy and relevance and, through this discussion, point out that the creation of a Ubiquitous Language is not the wholesale adoption of the language of the business, but rather, a unification of key concepts from both domain experts and the development team.

Sundials and digital Watches – The art of Time vs. the science of telling time

Sit in a room with domain experts and a development team for any length of time, and you’ll see one of the key differences between these two groups at play almost instantly. Let’s assume a meeting has been called by a technical project manager. Its purpose is to reason about an important feature for a new piece of software that the team is preparing to build.

Page 1 of 3 | Next page