Practical .NET

The Power of Talking About Your Business Processes Correctly

One of the biggest problems in designing applications is the conversion from how the business talks about the business to how the developers think about coding it. Domain-driven design has a solution.

• By Peter Vogel
• 08/12/2015

We've all had this experience: We build something, deliver it, the user starts it up and says, "Oh. That's not what I meant at aaaaallllll." Hopefully, you discover that early in the process and not after you've implemented the application.

On one project, I didn't make the discovery early enough: I helped deliver an application that worked well … provided the users were willing to spend four or five hours of overtime every day to get their work done. Two weeks after implementation I went from being "team member" to "project lead" with a mandate to make the application work the way the user actually wanted it to.

Missteps in converting from what the user says to what developers build isn't uncommon (and why developers who "understand the business" are so valuable). Domain-driven design (DDD) has a concept that's intended to address this problem: the ubiquitous language. I've discussed part of this concept in an earlier column. In that column I discussed how the definitions of words used in the organization (for example, "What is a customer?") don't apply across the whole enterprise. Instead, the meaning of "customer" is only consistent within part of the company. That understanding is core to DDD: The part of the company where one set of terms do have constant and consistent definitions defines a "domain" within the company.

But equally important to the concept of the ubiquitous language is how those words are used. The team uses those words to describe business processes within the domain. The problem is that it's very easy to generalize these process descriptions, especially if you're trying to come up with a description that applies across the whole enterprise. DDD says you should abandon that attempt to describe "enterprise-wide" processes and, instead, concentrate on accurate descriptions that only apply within the domain.

The Power of Specific Descriptions
For example, it's very easy for the head of a business to say, "We make money by selling products to customers." And, at a very high level (the boss's level), that statement may well be true. However, if you start creating applications based on this description, you end up writing code like this:

Dim prod As New Product("A123")
Dim cust As New Customer(36978)
prod.Sell(cust)

The issue is that general terms conceal specific differences and details. If, for example, you drill into the details of one domain -- the billing department, for example -- you discover that the general description provides no guidance at all in writing your code. Within the billing department domain, you find that a more accurate description of getting money from customers is something like, "We invoice customers based on a sales order whose price is determined according to the contract we have with the customer and any adjustments we make to the sales order."

That definition leads to a very different set of code. Something like this, for example, matches what the billing department actually does:

Dim so As New SalesOrder("36978102")

Dim adjs As List(of Adjustments) 
adjs = Adjustments.GetAdjustments(so)

Dim cust As New Customer(36978)
Dim cont As Contract = cust.GetContract(ContractType.CurrentYearSales)

Dim inv As Invoice = cont.Purchase(so, adjs)
cust.Invoices.Add(inv)

It might be possible to make the code (with the prod.Sell method) work, even for the billing department. However, as the company evolves over time or as new functionality needs to be added to support contracts or adjustments, the application will become increasingly more complicated and unmaintainable. And, let me point out, I only said that it might be possible to get the prod.sell code to work.

Developing the Ubiquitous Language
Smoothing the transition from business description to application code is the primary goal of the ubiquitous language: Descriptions in the ubiquitous language are the way the team communicates among themselves, from the business analysts describing the organization, right down to the developers specifying the code for the application. The goal of the ubiquitous language is to eliminate any transition from "business-speak" to "technical-speak" (or, if you prefer, from "suit-speak" to "geek-speak"). Ideally, no conversion is required and no conversion errors can happen.

Getting to a ubiquitous language isn't something that happens overnight, isn't something you'll get right the first time and isn't without its own special pitfalls (it's very easy for the descriptions in the ubiquitous language to be more about wishful thinking than the realities of how the organization works, for example).

As team members start to use the language, they'll discover that some of the initial definitions are ambiguous. As the team starts describing the business processes, all of the team members will discover that the language needs to be broadened to describe those processes in a way that's natural to the organization. The language develops out of constant communication among the team members, always grounded by references to specific cases (when it comes to developing the ubiquitous language, you can't have enough examples of actual instances of the processes in action).

But, in fact, that's what supposed to happen. The act of developing the ubiquitous language is the process of defining the application in a way that makes sense to all of the team members.