A Shared Language Between Businesses and Developers
Ubiquitous Language is a common language between businesses and software developers. A model can be anything the people involved with the domain agree on. The Ubiquitous Language is another way to represent a model. The Ubiquitous Language is a shared language developed by domain experts and software developers. Domain-Driven Design models the ubiquitous Language per Bounded Context. Ubiquitous Language reflects the structure of the model. The systems that the model suggests should show up in the Software.
Ubiquitous Language is so important because we generally have an issue called the “cost of translation.” The business uses Language natural to the business to describe its requirements. We have two layers of indirection here, costing our industry money. In recent years our industry has started searching for a solution to reduce the “cost of translation” at different levels. BDD scenarios as a domain model. What if we stopped separating these efforts? First of all, you and your entire team are getting a clear understanding of the business concept behind the user story you’re developing. But even more, you’re also getting a choice at which level to start implementing this feature. Yes, you can still go through the web interface using a web crawler, but what if you decide to develop the domain core first instead?
Developers are starting to realize there are better ways to design a product than mixing the problem and solution spaces. End-to-end automation is the most common way of using Gherkin-based BDD tools. The first thing people think about when they see Gherkin is, “I can test my website with this.” You can use your scenarios written in Gherkin to drive the implementation of the lower layers of your application. Scenarios written this way describe how you plan to implement the feature, not what behavior you support. It is one of the two most essential concepts in BDD in which the requirements represent a change in behavior across time.
A bounded context is a business domain, in the broad sense, is what an organization does and the world it does it in. A bounded context is a complete, well-defined business domain model. Bounded contexts are data and code. When using DDD, the goal is to create a Bounded Context. It is a desirable goal to align business sub-domains or departments one-to-one with Bounded Contexts.
At the implementation level, bounded contexts are deployable units of the Software. In Ruby, a Bounded context might be a gem. The internal structure of the gem can be defined with namespaces. Bounded Context exposes concepts from a single domain. In this context, actors represent stakeholders or users from the real world. These Actors direct change. We want to partition the system so that a shift in one actor does not affect the other. e.g.`Finance::Orders`. Where `Finance` refers to the stakeholder or group of stakeholders who are getting the value from the solution.
To deliver good Software, we must focus on the complexity of the whole business rather than on the technical part of it. The tools are only relevant if the efforts to solve a problem point in the right direction. Complexity in the domain is not anymore according to the problem, so we don’t have to speed up coding. We don’t have to use frameworks to type faster, scaffold code, etc. That’s not the problem anymore. Using tools to deliver Software faster doesn’t mean that the final solution will end up working, be cost-effective, or even be able to scale. No, that is not happening because, yeah, the knowledge about the problem domain is not that it is sophisticated. It’s not ready to be turned into Software.
[¹]: Domain-Driven Design: Tackling Complexity in the Heart of Software
