Ubiquitous Language in Domain-Driven Design and Business Behavior
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. They come back and see if that corresponds to what you’re using in your system now and when. Domain-Driven Design models the ubiquitous Language per Bounded Context. Ubiquitous Language reflects the structure of the model. The methods that the model suggests should show up in the Software. The actual complexity of Software lies in understanding the domain. To deliver the proper 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 no longer 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. The real problem in a complex project is understanding the goal complexity more by understanding the right thing to write.
A domain is what an organization does and the world it does it in. A domain is any formalization of a process. We share that the domain doesn’t change anything about an environment. We could use diagrams as we could use plain text.
Business rules are rules or procedures that make or save the business money. Business rules describe the operations, definitions, and constraints that apply to an organization. Business rules define business constraints. Business rules are intended to assert business structure or to control or influence the behavior of the business. What DDD help us with is identifying such rules and sharing them with both parties. We let the design emerge. We do emerging requirements. We come up with something, so we need to adapt. Only try and know some things. They can become useless, but planning is indispensable proper? It prepares you to succeed. It’s in the beginning; you need help getting anywhere. Okay, with agile, I still want to have a plan, and I want to plan to achieve.
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. Working Software is the last state of domain knowledge. The point of connection between DDD and BDD resides in the improvements for collaboration. DDD is the domain, while BDD is the business process behavior. The domain model represents what the Software is about. Every program is a sequential description of a manual process. The combination of a group of business behaviors represent. To understand the reasoning behind Model-Driven Development and how DDD influenced it.
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. There needs to be business information in the first scenario. It describes how you plan to implement the feature, not what behavior you support. It is one of the two most essential concepts in BDD, and the first scenario does not represent or use Ubiquitous Language, while the second one does.
DDD is all about sharing and publicizing the mental model between interested parties. DDD is about a shared mental model. It accomplishes this by emphasizing the promotion of the Ubiquitous Language as part of its main principles. With Domain-Driven Design, the goal is to reduce complexity by separating the essential things from the important ones.
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?
[¹]: Domain-Driven Design: Tackling Complexity in the Heart of Software
