Ubiquitous Language and Bounded Context in DDD

Evans' Domain-Driven Design: Tackling Complexity in the Heart of Software is the best book on designing really large enterprise applications I've read. Apparently this opinion is shared by many other developers and designers, because Entity and ValueObject, Repository and Specification are found in almost every large code base. But here is bad luck, Ubiquitous Language (single language) and Bounded Context (the context of the subject area) in foreign code I have never seen. And here a very large dog is buried.

Why do we need a single language?

Sometimes, in our profession, formulating a product requirement is more difficult than realizing it. Different subject areas are complex in their own way. In transportation you will come across the concept of overbooking, in sales with “special offers”, in trading with “stop-loss trailing orders”.

One language is the basic concept of dealing with complexity. If the subject area requires study, then let's not make things even more complicated and make people understand your domain model as well . We will call things the same way both in the specification and in the code. The example below illustrates the use of this concept:

A Common Language on

var ticket = cashdesk.Sale(seat, count); // Это может понять даже не технический специалист

Single language off

ticket.State = TicketState.Sold; // А это нет
ticketRepository.Update(ticket);

I felt the problems with the lack of a unified terminology in my own skin. The team was developing a system for selling tickets to events online. The new version of the product was designed to replace the old one, expand the functionality and fix the design errors of the first version. One of the major shoals of the first system was the assumption that only one ticket per seat could be sold. But it turned out that there is a "dance ground" and a "table for 5 people", which are convenient to represent with one place in the hall.

So the programmers got the abstract concept of “place to sell”, linking a place in the hall with the number of tickets that can be sold for this place. For ordinary halls with rows and seats, it was equal to one, and for a dance stall it was limited to the capacity of the hall.

Have you noticed how difficult the previous paragraph is?

From a technical point of view, the problem was solved ideally, but each subsequent programmer had to explain what the selling place is, how it differs from the quota and why it is called a ticket in the UI. As a result, this confusion resulted in a very unfortunate mistake in assessing the complexity of the sprint and the sprint was a failure.

Why do we need contexts?

Problem number 1

Unfortunately, we do not get the benefits of a single language for free. A single language requires a painstaking analysis of requirements and consultation with domain experts. Often, so-called experts voice opposing points of view about business processes and terms. By developing applications within the framework of a “single language”, you invest a lot of time in creating an internal customer knowledge base. This is certainly good. The problem is that almost certainly this work is not budgeted for the development of the application. Development according to all the canons of DDD and using a single language is an expensive and not quick pleasure.

Problem number 2

A “single language” is not really a “single language” for the entire application and lives only within the context. And Evans writes directly about it. Unfortunately, in the book this fact is formed softly, more likely as a recommendation, not a rule. I would type the paragraph in red CAPSOM and frame it. An attempt to create a single domain model is doomed to failure. One and the same term can mean different things in different contexts. I can immediately name a few examples from different subject areas, but they all require a special explanation, so I will limit myself to a synthetic example: recursive salad - tomatoes, cucumbers, lettuce. Well, you understand ...

Problem number 3

No one needs an entire domain model. It is likely too complicated even for the tough strategists and analysts. These guys will be asked to provide them with data in a completely different, understandable form and section. Contexts implement the principle of "divide and conquer", which helps to quickly train users and connect new members to the development team.

As a bonus

Bounded Context is an implementation of the principle of weak coupling at a higher level - at the level of a subsystem (module). Such segmentation will allow you to more flexibly manage the development, up to eliminating or rewriting entire modules from scratch, possibly even with a complete replacement of the team and / or the module technological stack. If you ignore the Bounded Context and expand and expand your domain model, sooner or later it will end up in the fact that the cost (both in time and in money) of any change in the system will tend to infinity.