Model-Driven Design with BDD and Ubiquitous Language

Ubiquitous Language is so important because we generally have an issue called the "cost of translation."

Developers are starting to realize there are better ways to design a product than mixing the problem and solution spaces. DDD is about a shared mental model.

DDD is all about sharing and publicizing the mental model between interested parties.  It accomplishes this by emphasizing the promotion of the Ubiquitous Language as one 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. 

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?

Drive your system’s design with natural abstractions. 

Natural abstractions are how we describe complex concepts. Natural abstractions are simple concepts that we use to explain complicated concepts. A model can be anything the people involved with the domain agree on. Ubiquitous Language is a common language between businesses and software developers.  The emphasis should be between those business concepts and the code definition of the same concept.

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 bound context. Ubiquitous Language reflects the structure of the model. The systems that the model suggests should show up in the Software. 

We use these abstractions in day-to-day conversations with stakeholders and programmers. 

The Language we share to communicate ideas about a system is the concept we need to map within the code. Everything starts at the level of a rule or a need that someone has. That's why the definition of User Stories has to be as abstract and near to the Language of the business as possible. The first to identify is an easy way to expose or share valuable concepts for those needing the solution.

In describing any need, many concepts might be necessary to the user. 

By looking at how the condition refers to actions and names, we can grab most of the abstractions we need at least to start experimenting. User Stories follow specific characteristics that make them reusable. For instance, When defining a User story, using a declarative style over an imperative one is preferable. The imperative style is too concrete and specific, reducing flexibility and expression. Making user stories declarative suggests an abstract language to describe the problem. 

After extracting some of the concepts embedded within a rule, we can start deciding how to put this concept in place in code. 

There are two types of artifacts during development. One part is primary data, and the other part is behavior. I will use a different name to refer to the same thing here. I will come from behavior `actions` and data `state .`Both items need to be separated. Yet, we need to find a way to make them work together. Here is where the usage of some of the concepts from Domain-Driven Design comes in handy. 

The application layer orchestrates the relationships between external input and internal interfaces while maintaining the state. 

Think is a glue layer between HTTP and any business domain. The application layer is a layer that surrounds the domain model and is the bulk of the application. The domain model defines the minimal and essential algorithms of a system. The application layer provides `interfaces` to interact with the impure external world and our pure internal one. We can use value Objects to represent raw business data. To know what a value object is, we need to ask, `Is the data more important than the behavior?` if yes, then we are dealing with a value object.

Data can be represented in code in several ways. 

Value Objects are the most valuable pattern when implementing a domain model in code. Since data represents the state, there are implications of having global access to our application's state. That's why we want to restrict the updates to the data at the application level. We can enforce this notion by transporting pieces of information within the system as Value Objects. The advantage of this approach is that we can enforce an immutable state across the system's internal parts. 

Immutability prevents side effects, thus protecting from direct access.

Immutability also promotes stability by avoiding side effects. Encapsulation restricts direct access to object internals. Thus, a software system enforces encapsulation by reducing side effects. Design your program as a core of independent functional pieces in this style. 

A story is always something that the business values. 

Think of a story as a thin vertical slice through the horizontal layers of the system. User Stories make the team focus on how the product will behave rather than how it will be built. User stories are independent of each other. User stories should not contain every detail for the implementation.  A user story must be concrete enough for developers to estimate it. The story must have clear and quantifiable value to the company. Every user story is an application layer service documenting what the system does.

The main advantage of User Stories is sharing the model in which a user thinks about the system.

Instead of focusing on how to build something, delivery teams consider how their products will be used. Ideas can be debated and analyzed by defining the expected behavior in a shareable form. Refactoring is never a story. Architecture is never a story. Code cleanup is never a story.

In describing any need, many concepts might be necessary for the user. 

By looking at how the condition refers to actions and names, we can grab most of the abstractions we need at least to start experimenting. User Stories follow specific characteristics that make them reusable. 

The standard way to write User Stories follows a specific template:

To <Behavior change>

As <Role>

I want to <Expected outcome>

Behavior change: This is the behavior the team wants to influence in a user. User stories describe the higher-level behavior of a user.

Role: Which Role will the user play in the Behavior change context? Defining roles is essential to split and group functionality based on users.

Expected outcome: Describe the result of the behavior change. The functionality that users and developers agreed on.

User stories expose business vocabulary.

Identifying the concepts, the user story describes the code base, and alignment solidifies. The following is a definition of a user story for an appointment scheduling software with a list of an initial group of business concepts. 

To see patients at a specific time and date

As a Doctor

I want to be able to schedule appointments with my patients.

Some of the concepts that we can start to use and define with stakeholders might be something like the following:

To see

Patients

Patient

Specific Time and Date

Doctor

Schedule

Appointment

After identifying the business concepts, we can define questions to discuss with stakeholders.

• Does a doctor have a different way of identifying?

• How many appointments can a doctor have in a day? Is there any time limit?

• What is the preferred format for scheduling an appointment?

• Is there a limit on the number of patients a doctor can see daily?

User Stories are not complete requirements but tokens of conversations. It's more of a question than an answer.

User stories thus represent a contract between stakeholders and the delivery team. Creating a user story promises that the business stakeholders and the delivery team will meet at some point to discuss the details. A basic understanding of the Language used at the business level can propel alignment and effective execution for code delivery.