Refactoring and the Ubiquitous Language

I was reading this morning an interesting post to the domain driven design list. I began replying on the list but as my answer started to become more than one paragraph figured it might be better to drop the answer on the blog.

The basic scenario as described is:

What we used to call an ‘Actor’ on an Order is now going to be called.
‘Collaborator’ on a Form in the UI.Collaborator is not a bad word, its a quite good.
Should I now do search and replace in our code in order to use the new word ?
 

This is a very common scenario when working with a domain model over a period of time. What something is called changes. This is especially prevalent when we are working on a domain model where we start out with a naive viewpoint as is often the case in non-formalized models. In these cases very often in business experts are “learning as we are doing”.

The asker goes on to mention:

My Product Owner (PO), and team member would think I had been smoking crack or
worse if i came up with a suggestion like that.
Anyway We have used the old word Actor in a webservice contract, so that is not
easily changed. (I know i could introduce ‘Collaborator’ and by time make actor
obsolete.I know common sense would suggest not to get religious, and simply accept the
old word. How ever i do feel tempted to use the new word.Eric Evans uses a term like “Hammering the ubiquitos language”. Which i
understand as “Its really really important to use the language/ concepts of the
Project Owner/Users”

A few people have jumped in with responses. Many suggest that doing the refactor is ok.

Dan Haywood mentions:

I have to say that we change names all the time.  But then, I work with naked objects-pattern [1] frameworks [2], [3] where there are very few DRY violations… so it’s no great hardship.
 

There is however a subtlety in the question that seems have been missed by many and it is actually a huge problem when dealing with the Ubiquitous Language. Going through and renaming Actors to Collaborators inside of the model is not really a big deal and should be done. However the asker mentions as well a webservice contract!

The webservice contract is a wire protocol. Generally we do not just “refactor” wire protocols. The reason why is that doing so is a breaking change for clients. If we broke the wire protocol we would as an example need a big bang release of all consumers of the protocol as well as ourselves. This causes quite a dilemma when talking about refactors for the purpose of the ubiquitous language. Wire protocols are harder to change and require more planning than internal models. This is an issue that is too often overlooked.

The first question that needs to be asked is. By default will we be upgrading all clients concurrently with the backend anyways? If so then no big deal. I know of many frameworks that use this model. This does however necessitate a big bang release. If you have many disparate clients or are risk adverse for deployments this may not be possible. I believe the naked objects framework mentioned by Dan takes this approach though after seeing some presentations they may be on the third option today.

Note that very often people think incorrectly about this question. If my domain is used in a web server as example then I blue/green deploy it would seem I would be ok (client is the web server). But what if some received a page from the first then posted to the second. This may be an entirely acceptable business risk but remember it exists.

The next question is. Do we want to versionize our wire protocol. I could always take our old method that includes actor and create a new method that then uses collaborator. Old clients could still use the old one new clients would use the new one. We could even deprecate the old method after some period of time. You can imagine however with non-matching UIs and various versions around this can get confusing both for the dev teams and for the developers. We have to be very careful when dealing with messaging contracts.

A third option exists. The third option is not something that we can do at the point in time of the question as we would have had to make a decision much sooner in the development process. What if instead of using webservice contracts we had decided to use a HATEOAS RESTful api? With such a client I could make changes like this without affecting any of my clients.

It is important to remember that data on the inside is often different than data on the outside. A HATEOAS based api will often help isolate yourself from these types of changes in the future. There are however very few people using HATEOAS based apis over domain models. Instead largely due to tooling that is being given to us “restful” tends to mean “expose my objects as resources”. The question above is the exact situation that a HATEOAS based api can serve well. Keep these kinds of scenarios in mind early when choosing an api over your model!

5 Comments

  1. Posted February 13, 2013 at 4:14 pm | Permalink | Reply

    Tooling aside, can you speak to the relative difficulty of developing a HATEOAS ‘shell’ vs a more traditional one, like WCF / MVC?

    • Posted February 15, 2013 at 9:00 am | Permalink | Reply

      It’s described in the link to Wikipedia that Greg posted. Briefly, the traditional approach consists of a fixed contract for all services, like a pack of WSDL schemas with documentation. HATEOAS means a simple entry point with services returning ‘links’ to other services, just like hyperlinks on the webpage. Of course the whole idea is much richer than that, check out this cool book to learn more: http://www.amazon.com/REST-Practice-Hypermedia-Systems-Architecture/dp/0596805829

  2. Posted February 13, 2013 at 7:46 pm | Permalink | Reply

    Specifically, how do you envision addressing the OP’s issue with HATEOAS? The use of the name ‘Actor’ vs ‘Collaborator’ would be part of the media type. Use of hypermedia would allow the root resource to point clients to a new resource and media type, however the clients would still need to know how to interpret the new media type. At this point, this becomes very similar to the versioning solution.

    • Posted February 14, 2013 at 1:10 am | Permalink | Reply

      Depends on our media types. Alternative links are a good start.

  3. Posted February 15, 2013 at 2:19 pm | Permalink | Reply

    The little issue with HATEOAS is often the link relations are themselves part of the ubiquitous language. Therefore, when the concept pointed by the relation changes name, you are back in square one. Especially since the relations are often describing verbs.

One Trackback

  1. [...] post was inspired by a blog post by Greg Young, which was in turn inspired by a question on the DDD mailing list. Here are some of my experiences [...]

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

Follow

Get every new post delivered to your Inbox.

Join 7,557 other followers

%d bloggers like this: