Did I understand Ports & Adapters/Hexagonal architecture correctly?

Question

The Ports and Adapters architecture aims at building decoupled code. The Domain layer does not depend on the Infrastructure layer directly, instead it depends on the port (the interface) and the implementation of the port is in the Infrastructure layer, right?

My folder structure will be as such:

1. A project for my UI

2. A project for the core of the application, which contains Application Service, Domain Services and Domain Models.

3. A project for the ports: It contains strictly interfaces.

4. A project for the infrastructure, and I have a persistence folder in there.

The delivery mechanism can be switched (from console app to web app...) and the Core will still work the same.

Same for the infrastructure, I could be using entity framework for once and then switch to dapper without causing a change in the Core.

So far so good, or did I miss something along the way, or did I miss the very basic understanding of the architecture?

Now code wise:

If I have a console app where I have to type a command and it creates a customer.

A class from the Application Service found in the Core project. It uses dependency injection to access the implementation of IPersistence.

    public class AddNewCustomer
    {
        private readonly IPersistence _persistence;

        public AddNewCustomer(IPersistence persistence)
        {
            _persistence = persistence;
        }

        public bool addToDb(customer customer)
        {
            return _persistence.add(customer);
        }

    }

The interface in the port project.

    public interface IPersistence
    {
        bool add(Customer customer);
    }

The implementation in the interface project.

    public class Persistence: IPersistence
    {
        public bool add(customer customer)
        {
           //inserts into DB
        }
    }

Is the port project supposed to be strictly about interfaces? How do you structure (folder structure) your ports and adapters project?

Answer 1

So far so good, or did I miss something along the way, or did I miss the very basic understanding of the architecture?

I will try to express myself correctly. Hope it helps.

The Ports and Adapters architecture aims at building decoupled code.

That's true. But it isn't the main goal "per se". It is a way to achieve the main goal, which is to be able to test the application in isolation from external devices (hardware, software, humans, ...) that fall out of the scope of the application.

The Domain layer does not depend on the Infrastructure layer directly, instead it depends on the port (the interface) and the implementation of the port is in the Infrastructure layer, right?

You are talking about layers. Hexagonal architecture pattern doesn't. It just says that you have the application (the hexagon) with ports, through which external real world devices (called actors) interact with the application. Ports belong to the application (which is technology agnostic), and the port-actor interaction is done through a technology dependant adapter.

A project for the core of the application, which contains Application Service, Domain Services and Domain Models.

Here I would just like to comment that Hexagonal architecture pattern doesn't say anything about the internal structure of the application (the hexagon).

The delivery mechanism can be switched (from console app to web app...) and the Core will still work the same.

That's ok. Console and web apps are adapters who drive the application. They use the driver ports (ports that offer the application functionality to the external actors).

I could be using entity framework for once and then switch to dapper without causing a change in the Core.

That's ok. They would be adapters for the persistence port, which is a driven port (a driven adapter implements a driven port to interact with an external actor).

Is the port project supposed to be strictly about interfaces? How do you structure (folder structure) your ports and adapters project?

I have a "java 9 module" for the hexagon (you call it Core). And the ports are module packages that I export. Each port is a package, with a service interface defining the operations of the port. But you could have more classes (representing the operation arguments, mappers if you don't wanna expose the internal objects to outside world,...). Implementation is up to you.

My folder (java packages) structure is:

Hexagon:

[app-name].hexagon.internal = the inside of the application

[app-name].hexagon.driver.[driver-port-name] = one or each driver port (API of the application)

[app-name].hexagon.driven.[driven-port-name] = one or each driven port (SPI of the application)

Adapter between a port and an actor using a technology:

[app-name].adapter.driver.[driver-port-name].[actor-name].[technology] = one for each driver adapter

[app-name].adapter.driven.[driven-port-name].[actor-name].[technology] = one for each driven adapter

I have written an article about Hexagonal architecture where I explain the pattern, and I'm about to publish an implementation example. If you wanna read it, here is the link:

https://softwarecampament.wordpress.com/portsadapters

Hope it helps.