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

First, let's discuss what a use case actually does. Usually, it follows these steps:

1. Take input.
2. Validate business rules.
3. Manipulate model state.
4. Return output.

A use case takes input from an incoming adapter. You might wonder why this step was not called "Validate input". The answer is that use case code should care about the domain logic, and we shouldn't pollute it with input validation. So, we'll do input validation somewhere else, as we'll see shortly.

The use case is, however, responsible for validating *business rules*. It shares this responsibility with the domain entities. We'll discuss the distinction between input validation and business rule validation later in this chapter.

If the business rules were satisfied, the use case then manipulates the state of the model in one way or another, based on the input. Usually, it will change the state of a domain object and pass this new state to a port implemented by the persistence adapter to be persisted. A use case might also call any other outgoing adapter, though.

The last step is to translate the return value from the outgoing adapter into an output object that will be returned to the calling adapter.

With these steps in mind, let's see how we can implement our "Send Money" use case.

To avoid the problem of broad services discussed in the chapter ["What's Wrong with Layers?"](https://www.educative.io/courses/hexagonal-architecture-web-apps/promotes-database-driven-design), we'll create a separate service class for each use case instead of putting all use cases into a single service class.

## Creating the `SendMoneyService`  class

Here's a teaser:

First, let's discuss what a use case actually does. Usually, it follows these steps:

1. Take input.
2. Validate business rules.
3. Manipulate model state.
4. Return output.

A use case takes input from an incoming adapter. You might wonder why this step was not called "Validate input". The answer is that use case code should care about the domain logic, and we shouldn't pollute it with input validation. So, we'll do input validation somewhere else, as we'll see shortly.

The use case is, however, responsible for validating *business rules*. It shares this responsibility with the domain entities. We'll discuss the distinction between input validation and business rule validation later in this chapter.

If the business rules were satisfied, the use case then manipulates the state of the model in one way or another, based on the input. Usually, it will change the state of a domain object and pass this new state to a port implemented by the persistence adapter to be persisted. A use case might also call any other outgoing adapter, though.

The last step is to translate the return value from the outgoing adapter into an output object that will be returned to the calling adapter.

With these steps in mind, let's see how we can implement our "Send Money" use case.

To avoid the problem of broad services discussed in the chapter ["What's Wrong with Layers?"](https://www.educative.io/courses/hexagonal-architecture-web-apps/promotes-database-driven-design), we'll create a separate service class for each use case instead of putting all use cases into a single service class.

# Creating the `SendMoneyService`  class

Here's a teaser:

Let's look at a use case to guide us on what we need to build.

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

A Use Case in a Nutshell