Hexagonal architecture: Dependency between core and outbound adapters?

Question

An excerpt on hexagonal architecture from a book:

...instead of a data persistence tier, the application has one or more outbound adapters that are invoked by the business logic and invoke external applications. A key characteristic and benefit of this architecture is that the business logic doesn’t depend on the adapters. Instead, they depend upon it.

It's a bit confusing to me. First it says 'outbound adapters that are invoked by the business logic', and then it says 'the business logic doesn’t depend on the adapters. Instead, they depend upon it.'.

Are not these 2 contradictory? If business logic has to invoke outbound adapters, then it means it depends on those adapters, not the other way round.

René Link · Accepted Answer · 2023-03-16T07:17:15.727

The business logic depends on abstractions, not the implementations.

The business logic only has a dependency to an interface. So the business logic has a "uses" dependency on that interface. This interface is called a secondary port in the hexagonal architecture. The interface is also often called Repository. A term that is more common in the clean architecture.

The adapter has an "implements" dependency on that interface.

 +----------------+  uses    +------------+   implements  +--------------+
 | business logic | ------>  | Repository | <------------ | DBRepository | 
 +----------------+          +------------+               +--------------+

The princliple that is applied here is called the dependency inversion principle:

High-level modules should not import anything from low-level modules. Both should depend on abstractions

Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

As a result you can easily replace the repository impelemtation, e.g. for testing purposes. So that you don't need to startup a database to test the business logic. The test will be a lot faster then.

In order to have a good abstraction you have to keep the interface technology agnostic. E.g.

public interface BadRepository {
      public List<Offer> findOffers(String where); // Upps we exposed the 
                                                   // implementation technology 
                                                   // to the client.
                                                   // because the "where"
                                                   // parameter is
                                                   // usually a SQL where statement.
}

So you should either hide the details:

 public interface GoodReository {
      public List<Order> findOrders(OrderCriteria oc);
 }

Thanks for the input. It brings to me another question here. Suppose I have a repository interface, implemented by diff data stores to handle diff use cases(SQL, message broker etc). Now a change comes which needs a change in repository impl, but for a specific data store only. So it makes this abstraction tightly coupled now as I need to make change in all implementations even when not needed. Any input on this? — Mandroid, Mar 16 '23 at 07:58
First of all: yes if you change the interface then you have to update all implementations. But when I need to change the interface, because of the needs of one implementation, it looks like there is wrong definition of the interface. E.g. Usually the `findOrders` example above only needs a change in the implementation if you use another kind of data store - switching from SQL to NoSQL. It is also a good idea to make use case specific interfaces. E.g. a PlaceOrderUseCase defines a PlaceOrderRepository interface. This is called the interface segregation principle. — René Link, Mar 16 '23 at 08:29

Hexagonal architecture: Dependency between core and outbound adapters?

1 Answers1