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

In the [previous chapter](https://www.educative.io/courses/hexagonal-architecture-web-apps/promotes-database-driven-design), we discussed the potential problems that arise when using a layered architecture. This chapter will discuss an alternative approach. We'll start by discussing two of the SOLID principles and then apply them to create a "Clean" or "Hexagonal" architecture that addresses the problems of a layered architecture.


# SOLID

SOLID consists of the following five principles: 

* **S**ingle Responsibility Principle
* **O**pen-Closed Principle
* **L**iskov Substitution Principle
* **I**nterface Segregation Principle 
* **D**ependency Inversion Principle 

You can read more about these Principles in *Clean Architecture* by Robert C. Martin or on [Wikipedia](https://en.wikipedia.org/wiki/SOLID).

# SRP

Everyone in software development probably knows the #key# SRP: Single Responsibility Principle #key# or at least pretends to know it.

A common interpretation of this principle is this:

> *A component should only do one thing and do it right.*

That's good advice, but not the actual intent of the #key# SRP: Single Responsibility Principle #key#. 

"Doing only one thing" is actually the most obvious interpretation of a single responsibility,  so it's no wonder that the #key# SRP: Single Responsibility Principle #key# is frequently interpreted like this. Let's just observe that the name of the #key# SRP: Single Responsibility Principle #key# is misleading.


Learn about the single responsibility principle and how it can help you develop better software architecture.

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

The Single Responsibility Principle

SOLID