Dear Junior
I have gotten the delighting message from the Jfokus committee that they want me to speak at the Jfokus 2011 conference in Stockholm in February. I had proposed a presentation on the Domain Driven Design concept of Ubiquitous Language which they have accepted.
It seems to me that the ubiquitous language is one of the hardest things to get right. When I look at my own experience it is a part where there are a lot of small distinction, distinctions that are subtle but make a huge difference.
Just take an example of how you can express the same thing in different ways that seem synonymous, but actually make a huge difference.
Compare
"An account has a phone number. The account can change phone numbers."
with
"An account has a phone number. The phone number can be changed."
The difference might be subtle, but in a precise language the distinction is important. In the first case, the account have still the same (conceptual) phone number, which has been edited. The account and the phone number are both entities. In the second case, the account have changed its phone number to another phone number. In code the two cases would be
1. account.number.changeto(numbersequence)
2. account.number = new PhoneNumber(numbersequence)
So, what difference does it makes?
Well, somewhere else we might require that a new account might have the same number as an old account. Fair enough. But what happens if the old account gets a new number? Does the new account change its number as well?
Have we taken the pain to actually create a strict language that is understood in common, then we have the answer in the language. If we do not have that strict language, chances are high that we arbitrarily select one of them that "feels right at the moment". However, next time a similar situation arises there is no guarantee that what we pick arbitrarily that time is logically consistent with the first pick. Over time we risk getting a system that behaves subtly, or obviously, inconsistent with itself.
Of course, this is just one example. In the presentation, what I want to cover are practical aspects of to make a shared language to become useful - and what it takes to become useful. E g it has to be both rich enough to express the complexity of the problem, but it must still be precise enough so we can use it as a base to build a system.
Other aspects I want to cover is how such a language can grow over time (not a Big Upfront Design), problems and traps when introducing a new term, and the challenges of "mixed language environment" such as when there are both Swedish and English around.
Of course you recognize several of these subjects as we have discussed these earlier. However, I hope to put them together in a concise and structured format - and want to roll in some new ideas. I am sure there will be plenty of reasons to return to these areas in subsequent letter.
Yours
Dan