What is Domain-Driven Design and the principle of clean architectures? In this series of posts, we explain what it is, why we like it, and how to apply it. In this new post, we get to work modeling a specific functionality following the DDD philosophy.

In the previous post of this series on clean architectures and DDD, we introduced the basic concepts of this architecture and discussed the layered design philosophy, its elements, fundamental characteristics, and, of course, the advantages of its use.

At this point, it is worth asking how to take action. In other words, given a functional problem or a use case to implement, how do we apply DDD? Throughout this and the following posts in the series, we will cover the following points:

• Approach to a real functional problem.
• Application and use of ubiquitous language.
• Strategic design of the solution.
• Tactical design and implementation.

Problem: Control of operations in manufacturing

Let’s take as an example a characteristic digitization problem in a manufacturing company and its production flow, where operators must perform certain tasks to complete a work order that ultimately enables the manufacturing of a product.

The usual way operators work is as follows:

• For each work order they are given, they take one or more of the operations they need to perform, based on their knowledge and certifications, and begin working on them.
• They mark the task as assigned to the operator and in progress, so that no one else takes it again.
• Once the task is completed, they mark it as finished and return to the beginning of the process.

It is important to note, as a restriction, that operations can only be in one state at a time; that is, they are either to be done, in progress, or finished. In summary, their flow is as follows:

Let’s see how we can implement this problem!

Our ally, the ubiquitous language. Business concepts

The use of language on a project is subtle but all-important […] to create a supple, knowledge-rich design calls for a versatile, shared team language, and a lively experimentation with language that seldom happens on software projects.

 

Eric Evans – Domain-driven design. pp.23 – 24.

One of the most important parts of DDD is the language. From the team sessions (development team and domain experts, of course), a shared language must emerge that explains the model unambiguously. To achieve this, special attention must be paid to what the domain experts communicate to us.

For this particular example, we will take the previous explanation as the information we have from the domain (let’s imagine that it was an expert who provided it to us) and extract, in a brief manner, the most important concepts and entities:

• Operator: A technical user who performs the operations. Each operator has skills that will allow them to execute a specific operation or not.
• Order: A work order is the set of operations that one or more operators must carry out to produce a good or service, using certain consumable resources.
• Operation: Operations are the smallest unit of work that an operator must perform to complete a work order. All operations belong to a specific order, must be executed by operators with the necessary skills, and are changed in status during the operator’s workflow. They can be in one of three different states: TODO, DOING, and DONE.

Strategic Design: the moment of truth

During the strategic design phase, the development team, together with domain experts, must define the bounded contexts, the ubiquitous language, and the context maps that explain the domain of the problem.

To do this, it is recommended to follow, among other techniques, Event Storming. With this technique, we can define the behavior within our domain, identify the elements involved, and understand how they are related to each other. All this information will later help determine the building blocks of our software project.

Continuing with the proposed example, in the following image, you can see a model of the state change of operations.

From this image and its analysis, and following the Event Storming nomenclature, enough domain information can be gathered to make a first implementation. But we will leave that for the next post.

In the next chapter of this series, the tactical design and implementation of the solution will be carried out.