What is Domain-Driven Design and the principle of clean architectures? In this series of posts, we will explain what they consist of, why we like them, and how to apply them. To start, in this article, we will define basic concepts about layered architecture.

When tackling a new software project involving multiple stakeholders, various components or third-party systems, or aiming to implement large business workflows essentially, a project with a high level of complexity the same question arises: What design strategy should be adopted? What business language should be used? What technological architecture patterns should be applied?

The answers to these questions should always be based on the analysis of aspects such as the required maintainability, the level of integration, scalability, or simply the implementation cost. However, one key aspect is often overlooked: the language. This is nothing more than the mechanism or point of connection that should allow the link between the business world to be digitized and the final digital product. In other words, the aspect that will determine success.

At what point does the concept of clean architectures and DDD (Domain-Driven Design) come into play? How do they help work on and optimize this key aspect? To begin, this article will address basic architectural concepts.

Clean Architectures and the Magic Hexagon

The hexagonal architecture is based on the following fundamental principles and objectives:

• Explicitly and decisively separate the user, business, and server layers.
• Derive and push the dependencies from the user and server layers towards the business logic.
• Isolate and make each layer as independent as possible, eliminating improper couplings and giving each component a very specific responsibility.

From a practical point of view, this architectural principle is based on an idea as old as it is effective: divide and conquer. Separating or breaking the problem into independent pieces will not only make it easier to understand the overall problem, but it will also simplify the implementation of the solution and its subsequent maintenance. On the other hand, it paves the way for greater extensibility and scalability.

Would you like to dive deeper into this architectural principle? This article will be very helpful. Let’s explore briefly and concisely each of the main components of hexagonal architecture.

Presentation layer

It is simply the final user interface. Broadly speaking, it is responsible for displaying information to the user, interpreting their commands, and triggering the relevant business actions by communicating with the other involved layers.

It is important to highlight that, at times and quite frequently, the user or external actor is identified as a human being. Nothing could be further from the truth. The end user can be any other entity: a machine, an IoT device, another computer system, etc. This is a crucial point to consider when designing this layer.

Application layer

It defines the tasks that the software must perform and directs the expressive domain objects to solve the problems. The tasks handled by this layer are significant for the business or necessary for interacting with the application layers of other systems.

This layer remains “thin.” It does not contain business rules or knowledge; instead, it simply coordinates tasks and delegates the work to the domain object collaborations in the next layer. It does not have state that reflects the business situation, but it may have state that reflects the progress of a task for the user or the program.

Domain layer

Also called the model layer. It is the component of the architecture responsible for representing business concepts, information about the business situation, and business rules. The state that reflects the company’s situation through its digital system is controlled and used here, although the technical details of its storage are delegated to the infrastructure.

In short, it is the component that implements the company’s workflows or production processes using a language very close to the business domain.

Infrastructure layer

This layer provides the generic technical capabilities that support the upper layers: message sending for the application, persistence for the domain, rendering widgets for the UI, etc. It is also responsible for the connection with external systems/agents outside our domain.

The infrastructure layer can also support the pattern of interactions between the four layers through an architectural framework and is also referred to as the anticorruption layer because it prevents the business layers from being “contaminated” with elements that are actually external to it.

Would you like more information? Take a look at this post.

In the next chapter of this series, a real-world problem will be presented along with the design of the solution, applying this and other principles.