Update! 🎉 Here is the introduction to Domain-Driven Design or DDD that, after some time and learnings, we want to share following this post about Hexagonal Architecture 😊
Today we will set the principles about Software Architecture and, more specifically, about what Hexagonal Architecture is. After a first season where we talked about the SOLID principles, and we have seen the issues of tightly coupled code in terms of testability, we will take a leap in terms of Software design and focus on Software Architecture, or as Sandro Mancuso called it: "Macro-design".
Software Architecture
In this video, we will talk about Hexagonal Architecture, but first, we will introduce the concept of Software Architecture and justify in what context it would be necessary to propose a strategy to follow in this regard. We will support ourselves on the concept of Accidental Complexity vs. Essential Complexity to justify the need to establish some rules of engagement when designing Software that allow us to keep Accidental Complexity at bay.
Clean Architecture
After introducing the concept of Software Architecture, we will talk about "clean architectures" (😅) or Clean Architecture. These are a type of architecture that, as Uncle Bob suggests, establish a set of boundaries regarding the layers of our application, and propose a dependency rule between them that goes from outside in. This way, we avoid coupling our domain with more external elements, allowing for a high tolerance to change. It is interesting to explore this concept and see that it is something completely agnostic to the type of applications. While it is true that depending on whether we are making a mobile application or a REST API, we will have to consider certain specific aspects of our context, at the level of abstraction as proposed when discussing Clean Architecture, we can find significant common points. So much so that here you can see an example of Clean Architecture applied in Android, in iOS, or in PHP.
Layers architecture
Before diving into Hexagonal Architecture, it is important to highlight the difference with layer architecture or "Layers architecture". As we can see in the previous image, layer architecture would have the database at its center. That is, the domain would be aware of the persistence system and, therefore, would be coupled to it. We inevitably see this pattern when discussing applications based on Active Record. This type of applications is quite widespread in the Ruby on Rails world since, by default, this is what this framework proposes.
In contrast, in Hexagonal Architecture (also called Ports and Adapters), as we can see in the previous image, the database is conceived as one more of the ports with which our domain interacts. However, to carry out this interaction, we would always be applying the Dependency Inversion Principle so that we do not couple to the specific implementation of the database client, but to an interface (contract) that would reside within our domain.
Hexagonal Architecture
Why Hexagonal? Honestly, I prefer the alternative name "Ports and adapters".
- It does not mislead thinking of possible limitations of 6 layers (due to the hexagon).
- It incorporates the concept of "port" at a theoretical level, easily extrapolatable to the concept of interface at an implementation level.
- It adds the concept of "adapter," a design pattern widely used when applying the DIP.
What does it have to do with Domain-Driven Design (DDD)? Being an architecture that encourages our domain to be the core of all layers, and that does not couple to anything external, it fits very well with the idea of DDD. After all, the tactical part of Domain-Driven Design is nothing more than the grouping of many existing concepts and design patterns. Thus, we could say that DDD is based on Hexagonal Architecture as a central pillar in architectural terms. What benefits does it have? Mainly, and based on the fact of decoupling, we have benefits directly in the form of:
- High testability (Application of the Dependency Inversion Principle (DIP) of SOLID for domain interaction with other elements)
- High tolerance to change (Open/Closed Principle (OCP) of SOLID derived from the application of DIP)
- High code reuse due to the strict division of responsibilities at the level of Application Services and Domain Services (Single Responsibility Principle (SRP) of SOLID)
At the same time, it is also worth noting that, being based on the contracts established by the ports we define, it allows us to postpone decisions at the implementation level (which adapter we will implement for that port). This facilitates test-driven development (TDD) as we can focus on the class we are developing without the need to implement its collaborators at that strict moment. I recommend Eduardo Ferro's post on this: The art of kicking the can down the road / Postponing technical decisions. Without further ado, here is the video:
In future videos, we will detail each layer of this architecture and delve deeper through code examples. So, if you already have questions, feel free to raise them in the comments of this video so that we can tackle them in the following ones :D. Lastly, I also leave you the link to the post I mention in Fideloper's video, a great resource to start experimenting with this topic :