Is Ubiquitous Language Possible?

The Goal

There have been some interesting discussions recently about the importance of having a “common language” between developers and business domain experts.  DDD refers to this concept as its “Ubiquitous Language”:

“The concept is simple, that developers and the business should share a common language, that both understand to mean the same things, and more importantly, that is set in business terminology, not technical terminology.”

The intention is that once we share a common vocabulary, we can improve our requirements and design.  The class design (the business entities and their relationships) hopefully better reflects the true interactions of the business we are trying serve.

The Problem / An Example

The difficultly in identifying the “real names” typically lies somewhere between developers and the business domain experts.  However, on some very large projects, I seemed to have encountered another variation of this problem.

Let’s consider a large project, divided into multiple teams.  Each team is responsible to design and implement separate functionality, but each team has significant overlap with the other.

For example, imagine Really Big Company’s executive  management has decided to build an “improved” customized version of their current email system to communicate better with customers.  So, in assemblies our project teams, we decide to divide the project into two primary teams: Team A will build the “inbox” functionality, and Team B will build the contact management module.

Since Team A and Team B follow good DDD principles, they being working on creating their common language (shared names).  Team A discovers that the domain experts for the Inbox system refer to their mail recipients as “contacts”, and, ironically, Team B’s domain experts refer to their contacts as “customers”.

At some point, they realize that “customers” are really just one “type” of contact.  With this shared understanding, the developers create a design where [Customer] will be a subclass/child of [Contact].  The domain experts readily agree the improved design.

So now, developers will distinguish contacts from customers.  And the next time they hear domain experts refer to a “customer”, they think they can assume a[Customer].  The business agreed on it, right?!

So, the real question — did the business user really mean [Customer]?  Or did they really mean [Contact]?

Conclusion

It is unlikely that the vocabulary of the business users will change, especially when the business users are not part of the full time project staff.  Remember, the developer staff isn’t the only interaction that these domain experts will have!  So, even when we have “agreement”, it is unlikely (and probably undesirable) to change the language of the business.

So then what?

After all this, we may be tempted to throw out our ideas on common language, shared names, and ubiquitous language.  However, let’s stop to see what we have accomplished.

In our theoretical meeting, when the domain expert mentioned “customer”, the technical team can now ask “Do you mean [Customer] or [Contact]?”.  And, with any luck, the business now understands what we mean, and can give a simple answer.  “Ah, yes, you’re right.  I do mean [Contact]”.

Common language isn’t a cure-all.  But it sure helps.

I’m curious to hear your experiences as well.

About these ads

4 thoughts on “Is Ubiquitous Language Possible?

  1. I think this is where it gets quite interesting when you have two different teams working on different parts of the same overall system.

    It seems like maybe this is the time to think about the bounded context of each of the domain models? http://dddstepbystep.com/wikis/ddd/bounded-context.aspx

    If ‘Customer’ only makes sense in one area of the system then perhaps we wouldn’t let that term be used outside of that area.

    It sounds like in the case you describe that it might make sense to have it throughout the system in which case the two teams have a shared domain model.

    The Domain Driven Design book lists a range of different combinations of that idea:

    – ‘Shared Kernel’ where you have just part of the model the same
    – ‘Conformist’ where one team defines the model and the other puts up with it
    – ‘Bounded Context’ where the two teams would have separate models and use a translation layer to translate between their different meanings of the model.

    I think the key for me is that our discussions can become more productive if we’re all using the same names or at least driving to a situation where we are.

    • Mark, thanks so much for your comments!

      In situations where we need to further clarify or enhance the language of the business, I think the problem is most difficult (for example, when different business users use the same term for different things). In this case, the ubiquitous model may even cause us to incorrectly assume the term’s meaning even faster.

      In any case, I think we reached the same conclusion, and I fully agree with you that:

      “the key… is that our discussions can become more productive if we’re all using the same names or at least driving to a situation where we are”

      Thanks again for sharing your thoughts!

    • Oh, and I really like the idea of bounded context for the example I mentioned in the blog post. I certainly agree that the domain model can benefit from the separation, but I don’t really like the idea that the persistence is independent as well. It seems very redundant to have two versions of the same thing in the DB. Am I missing something? Thoughts?

  2. In that case would it work to have a single entry in the database and then with your ORM or whatever you could create a ‘CustomerDAO’ which maps from the database to that class.

    From that there would be some translation code to go from that into a Contact for one part of application and a Customer for the other part of the application.

    Would that work? Not sure!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s