Implementing Domain Driven Design - Day 6

We continue our series, again on chapter 4 about Architecture
Let's go 😆

A. Hexagonal Architecture

With the Hexagonal Architecture, Alistair Cockburn codified a style to produce symmetry. It advances this goal by allowing many disparate clients to interact with the system on equal footing. Need a new client? Not a problem. Just add an Adapter to transform any given client’s input into that understood by the internal application’s API. At the same time, output mechanisms employed by the system, such as graphics, persistence, and messaging, may also be diverse and swappable. That’s possible because an Adapter is created to transform application results into a form accepted by a specific output mechanism.

• 1️⃣ Diagram

• 2️⃣ Definition ?

We usually think of the place where clients interact with the system as its “front end.” Likewise, we consider the place where the application retrieves persisted data, stores new persistent data, or sends output as its “back end.” But Hexagonal promotes a different way of looking at the areas of a system, as indicated by Figure 4.4. There are two primary areas, the outside and the inside. The outside enables disparate clients to submit input and also provides mechanisms to retrieve persisted data, store the application’s output (for example, a database), or send it elsewhere along its way (for example, messaging).

• 3️⃣ The Left Side

Each client type has its own Adapter [Gamma et al.], which
transforms input protocols into input that is compatible with the application’s API—the inside. Each of the hexagon’s sides represents a different kind of Port, for either input or output. Three of the clients’ requests arrive via the same kind of input Port (Adapters A, B, and C), and one uses a different kind of Port
(Adapter D). Perhaps the three use HTTP (browser, REST, SOAP, and so on) and the one uses AMQP (for example, RabbitMQ). There is not a strict definition of what a Port means, making it a flexible concept. In whatever way Ports are partitioned, client requests arrive and the respective Adapter transforms their input. It then invokes an operation on the application or sends the application an event. Control is thus transferred to the inside.

• 4️⃣ The Right Side

What about the other side of the application, to the right? Consider Repository implementations as persistence Adapters, providing access to previously stored Aggregate instances and storage for new ones. As depicted in the diagram (Adapters E, F, and G), we might have Repository implementations for relational databases, document stores, distributed cache, and in-memory stores. If the application sends Domain Event messages to the outside, it would use a different Adapter (H) for messaging. The output messaging Adapter is the opposite of the input Adapter that supports AMQP and thus goes out a different Port from the one used for persistence.

B. Why The Hexagonal Architecture ?

A big advantage with Hexagonal is that Adapters are easily developed for test purposes. The entire application and domain model can be designed and tested before clients and storage mechanisms exist. Tests could be created to exercise ProductService well before any decision is made to support HTTP/REST, SOAP, or messaging Ports. Any number of test clients can be developed
before the user interface wireframes have been completed. Long before a persistence mechanism is selected for the project, in-memory Repositories can be employed to mimic persistence for the sake of testing. See Repositories (12) for details on developing in-memory implementations. Significant progress can be made on the core without the need for supplementary technical components.If using true Layers, consider the advantages of toppling the structure and developing based on Ports and Adapters instead. When designed properly, the hexagon inside—the application and domain model—will not leak to the outside parts. This promotes a clean application boundary inside in which use cases are implemented. Outside any number of client Adapters can support
numerous automated tests and real-world clients, as well as storage, messaging, and other output mechanisms.

C. Conclusion

Because the Hexagonal Architecture is versatile, it could well be the foundation that supports other architectures required by the system. For instance, we might factor in Service-Oriented, REST, or an Event-Driven Architecture; The Hexagonal style forms the strong foundation for supporting any and all of those additional architectural options.

see ya 😌