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

# Same input model

We might be tempted to use the same input model for different use cases. Let's consider the use cases "Register Account" and "Update Account Details". Both will initially need almost the same input, namely some account details like a description of the account.

The difference is that the "Update Account Details" use case also needs the ID of the account to be able to update that specific account. And the "Register Account" use case might need the ID of the owner so that it can assign it to them. So if we share the same input model between both use cases, we'd have to allow a `null`  account ID being passed into the "Update Account Details" use case and a `null`  owner ID being passed into the "Register Account" use case. 

# Smelly code

Allowing `null` as a valid state of a field in our immutable command object is a code smell by itself. But more importantly, how are we handling input validation now? Validation has to be different for the register and update use cases since one needs an id and the other doesn't. We'd have to build custom validation logic into the use cases themselves, polluting our sacred business code with input validation concerns.

# Exceptions



Learn how using different input models for different use cases helps us 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

Different Input Models for Different Use Cases

Same input model