1

I'm reading a lot about hexagonal architecture, but in all the examples that i'm looking, all folders and class ubication are different, and this looks a bit confusing to me.

package organization

I've done a simple spring boot application with below folder structure. Adapter folder contains implementation of repository interface and the rest controller.

In domain folder, I've model, which is a simple POJO, ports, that are interfaces of service class which contains all the business logic of Product, and the interface of repository which exposes the methods to be implemented in repository.

In another folder I've service implementation, and as i told before, with the business logic of product.

Is this a correct way to implement an hexagonal architecture for a simple use case? If not, why? Where i should put every class and why? This is what it's not clear...

Much appreciate!

Toni Montero
  • 43
  • 5
  • 1
    Hexagonal architecture is much more about the relationships between your implementations than it is about the organization of your source files/folders. – VoiceOfUnreason Apr 06 '21 at 20:19

2 Answers2

1

Hexagonal architecture doesn't say snything about how to organize the hexagon code (business logic). You can implement however you want to.

Take a look at these articles:

https://jmgarridopaz.github.io/content/articles.html

choquero70
  • 3,332
  • 2
  • 24
  • 40
1

You are totally free to organise your code however you wish. This is unrelated to hexagonal architecture.

With that being said, if you want to use hexagonal architecture efficiently, you should probably follow a domain-driven design, that is to say, you should organise your code based on domain/business logic, and not based on technical similarities.

For example, instead of having the following structure:

controller
    product
    cart
    customer
service
    product
    cart
    customer
repository
    product
    cart
    customer

DDD recommends the following structure:

product
    controller
    service
    repository
cart
    controller
    service
    repository
customer
    controller
    service
    repository

Once you've done this, if it helps, you could wrap these in three packages for the differents parts of the hexagonal architecture: user side, business logic and server side. This is something I've done in the past; it helps me keep the different layers clear.

userside
    product
        controller
    cart
        controller
    customer
        controller
businesslogic
    product
        service
    cart
        service
    customer
        service
serverside
    product
        service
    cart
        repository
    customer
        repository

Again, the structure of your packages is not the most important concept. The hexagonal architecture focuses on three principles:

  • Explicitly separate user side, business logic, and server side layers. A clear package structure helps, but you can separate these layers in other ways.
  • Dependencies go from user side and server side layers to the business logic. This is done by defining interfaces and adapters in the business logic (see below). The goal is that code in the user side and server side may be changed without impacting the business logic layer. For example, if you wish to change your repository from a MySQL implementation to a PostgreSQL implementation (in the server side layer), this change should not impact your business logic: the new implementation need only comply with the interface in the business logic.
  • Dependency injection: the business logic defines interfaces (commonly called "ports") and transformers ("adapters") with which the user side and server side layers must comply for communication.

It's a very DDD oriented architecture; the idea is that the business logic remain as close to the domain as possible, and unadulterated by technical requirements.

Chris Neve
  • 1,522
  • 15
  • 26