All too often, software projects can have great success near the early stages only to get bogged down during middle and end phases. This is a very frustrating and costly scenario for everyone involved. What generally ends up happening is that developers become surprised when their understanding of a feature does not match the understanding of the product visionaries. Also, the product visionaries themselves may decide what is correct only after seeing the “wrong” implementation.
Developers may then have to rewrite major sections of the code. This frustration can lead to hasty implementations. As the project gets behind, it might be decided to bring on extra resources to help out.
The problem is, that a project already behind schedule is in danger of becoming a tangled mess when multiple developers are now making hasty implementations.
To try and avoid this tangled mess, a helpful tool is found in Domain Driven Design. The DDD methodology puts an emphasis on the language of the problem you are trying to solve and enforces layers between your domain (the problem) and the details (CMS, Database, Templates, etc).
The first stage in DDD is to define a common language.
Ubiquitous Language is the term Eric Evans uses in Domain Driven Design for the practice of building up a common, rigorous language between developers and users. This language should be based on the Domain Model used in the software – hence the need for it to be rigorous, since software doesn’t cope well with ambiguity. 1
This process can start with vague and ill-defined terms and it’s up to the developer working with the product visionary to refine and clarify the common language. This process has multiple benefits. First, ambiguity is dealt with early. It helps to guard against those surprise misunderstandings that often cause the project to go awry. Second, developing the Ubiquitous Language (UBL) can be very helpful for a product visionary as a starting point to further think about he idea, and to possibly narrow or refine the scope. Finally, the UBL is a great starting point for any developer that comes on to the project after development and will help ease the learning curve.
To highlight what the UBL can look like, let’s take a look at a relatively simple example. Suppose we want to build an interactive menu that needs to be deployed across multiple sites and technologies. For this example, we will stick to WordPress and Drupal. This menu is going to list out a set of Categories and Terms.
Initially our UBL may look like:
Root Category: Groups terms and other sub categories, can contain multiple terms and multiple sub categories.
Sub Category: Has one root category and can contain multiple Terms.
Term: A word that can be associated with multiple entities. For example the term “Ancient History” could be a term under the Sub Category History, that has the Root Category “Books”. Many books could be associated (grouped by) the term “Ancient History”. A url and a count of entities in a term will be associated to the term.
Entity: A “thing” in the system. In the context of a CMS, this thing could be a blog post, a page or a custom content instance.
If you are familiar with Drupal and WordPress, you may already notice ambiguity. Let’s take the word “Category”.
In Drupal: A category consists of a taxonomy and terms.
In WordPress: The ‘category’ taxonomy lets you group posts together by sorting them into various categories.
In our UBL: The root category groups terms, and possibly sub categories that group terms.
Already we are getting complex!
This clash of language is common in my development experience. You can see how the word Category can mean different things depending on the context. For instance a WordPress developer and a Drupal developer may have different ideas about how to implement our deluxe menu category. Without the UBL clarification, the developers understanding and implementation may fly under the radar until later in the project phase, causing the need for rewriting code.
As developers and product visionaries build the UBL, whenever there is ambiguity like this, it is helpful to think in terms of the bounded context. The key point is that no one understanding / definition is correct without knowing what context you are in.
A Bounded Context is the boundary that surrounds a particular model. This keeps the knowledge inside the boundary consistent whilst ignoring the noise from the outside world. 2
To help resolve this ambiguity we can then take to the whiteboard, paper or drawing application to quickly sketch out an initial model with any the bounded contexts.
A quick sketch of what our domain model and bounded contexts look like so far. The purpose is to show the general relationships in our domain and the boundary lines of context. In fact, the relationship notation is likely too much detail for this stage of planning.
UBL is well worth the time and cognitive investment upfront. The time put in not only pays dividends all throughout the project lifecycle, it also helps to build a rapport early between the developer and visionaries which supports the notion of a team rather than silos. I hope you found the information here useful, comment below if you have any questions/suggestions.
All three of these books are also available at https://www.safaribooksonline.com/