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

Our architecture style does not address the problem of how our domain model is to be implemented. This is a blessing because we can do what seems right in our context and a curse because we don’t have any guidelines to help us.

A frequent discussion is whether to implement a rich domain model following the #key# DDD: Domain-driven design #key# philosophy or an "anemic" domain model. I'm not going to favor one of the two, but let's discuss how each of these fits into our architecture.



# The rich domain model

In a rich domain model, as much of the domain logic as possible is implemented within the entities at the core of the application. The entities provide methods to change state and only allow changes that are valid according to the business rules. This is the way we proceeded with the `Account` entity above. Where is our use case implementation in this scenario?

In this case, our use case serves as an entry point to the domain model. A use case then only represents the intent of the user and translates it into orchestrated method calls to the domain entities that do the actual work. Many of the business rules are located in the entities instead of the use case implementation. 

The "Send Money" use case service would load the source and target account entities, call their `withdraw()` and `deposit()`  methods, and send them back to the database[$^{5}$](https://www.educative.io/courses/hexagonal-architecture-web-apps/appendix-i#locking).

# The anemic domain model

In an "anemic" domain model, the entities themselves are very thin. They usually only provide fields to hold the state and getter and setter methods to read and change it. They don't contain any domain logic. 

This means that the domain logic is implemented in the use case classes. They are responsible to validate business rules, to change the state of the entities, and pass them into the outgoing ports responsible for storing them in the database. The "richness" is contained within the use cases instead of the entities.

# Rich vs. anemic

Learn the difference between rich and anemic domain models and which can help you write maintainable code.

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

Rich vs. Anemic Domain Model