Discover Hexagonal Architecture to create web applications with isolated, testable layers. Gain insights into designing clean, maintainable modules and advocating for suitable techniques for your application.

Get Your Hands Dirty on Clean Architecture by Tom Hombergs.png

spring.tar.gz

spring1

spring1-copy

blank

This course will teach you all about creating a web application in the Hexagonal Architecture style. Hexagonal Architecture promotes the separation of concerns by encapsulating logic in different layers of the application. This enables a higher level of isolation, testability, and control over your business specific code. 

You will learn how to design software modules and complete applications in a clean and maintainable manner, while also learning how to advocate for a certain technique given your application and constraints.

By the end of this course, you will have a greater understanding of how to implement software architecture, a key skill for any senior developer.

Hexagonal Software Architecture for Web Applications

If we have an `Account` domain entity and an incoming port `SendMoneyUseCase`, we might be tempted to use the entity as the input and/or output model of the incoming port, as the figure below shows:

# Using domain entities as input model

The incoming port has a dependency to the domain entity. The consequence of this is that we've added another reason for the `Account` entity to change. 

Wait, the `Account` entity doesn't have a dependency to the `SendMoneyUseCase` incoming port (it's the other way around), so how can the incoming port be a reason to change for the entity? 

Say we need some information about an account in the use case that is not currently available in the `Account` entity. This information is ultimately not to be stored in the `Account` entity, however, but in a different domain or bounded context. We're tempted to add a new field to the `Account` entity nevertheless, because it's already available in the use case interface. 

# Simple use case

For simple create or update use cases, a domain entity in the use case interface may be fine, since the entity contains exactly the information we need to persist its state in the database.

# Complex use case

As soon as a use case is not simply about updating a couple of fields in the database but instead implements more complex domain logic (potentially delegating part of the domain logic to a rich domain entity), we should use a dedicated input and output model for the use case interface because we don't want changes in the use case to propagate to the domain entity.

# Dangers of shortcuts

What makes this shortcut dangerous is the fact that many use cases start their lives as a simple create or update use case only to become beasts of complex domain logic over time. This is especially true in an agile environment where we start with a minimum viable product and add complexity on the way forward. So if we used a domain entity as an input model at the start, we must know when to replace it with a dedicated input model that is independent of the domain entity.

Learn how to use domain entities as an input or output model in your projects.

Before We Begin

What's Wrong with Layers?

Inverting Dependencies

Organizing Code

Implementing a Use Case

Implementing a Web Adapter

Implementing a Persistence Adapter

Testing Architecture Elements

Mapping Between Boundaries

Assembling the Application

Enforcing Architecture Boundaries

Taking Shortcuts Consciously

Assessment

Conclusion

Appendix

Using Domain Entities as an Input or Output Model