Onion-hexagonal architecture dependency confusion

Question

I have problem with understanding the meaning of dependency in hexagonal(port-adapter) architecture.

Here they have nice picture. What I don't see is what is the difference(implementation) from n-layer structure.

In onion/hex architecture the inner layers should be independent from outer ones, but how is it implemented(please note my java/spring background)

In N-layered you auto-wire the N+1th layer components. I see the direction of the dependency, but how can you revert it:-/

If I'm about to call outer layer, I will use interface. So the interface is in inner and implementation in outer layer. Now I'm independent on outer. This is it? It is just about where the API is placed?

Anyway the hex/onion should be independent from dependency resolution, so does it mean I should not use @Autowire, @Inject etc??

Thanks a lot for clarification in advance.

Answer 1

Wow, that's a lot of questions. I'll try to go through them one by one

In onion/hex architecture the outer layers should be independent from inner ones, but how is it implemented(please note my java/spring background)

With architectural patterns you see lot's of different interpretations, but this one strikes me as weird. The inner part of an onion pattern is your domain logic, while the outer parts are adapters to other domains or technologies (databases, webservices ...). You don't want your domain to depend on those technical details, so the outer part might depend on the inner part, but not the other way around.

In N-layered you auto-wire the N+1th layer components. I see the direction of the dependency, but how can you revert it:-/

This is called inversion of control. Your domain (inner part) often needs to call on adapters (e.g. your database access logic), so at run time there has to be a dependency. But at compile time you don't want such a dependency, in order to be able to replace the specific technology used. You do that by using interfaces and dependency injection. Example: Your domain might need access to a list of all Brands. For this purpose you create an interface like this:

public interface BrandRepository{
    public Set[Brand] all()
}

This interface is part of your domain. You of course have an implementation of that interface, maybe based on Jdbc (or a In-Memory-List, or a Web Service). This implementation(s) live in the outer layers of the onion. Since the implement the interface the depend on the inner part, as requested.

If I'm about to call outer layer, I will use interface. So the interface is in inner and implementation in outer layer. Now I'm independent on outer. This is it?

Yes

It is just about where the API is placed?

Difficult to answer: what is your API? Your domain model is the API for the adapters. The Adapters are the API of other parts of your system or other systems.

Anyway the hex/onion should be independent from dependency resolution, so does it mean I should not use @Autowire, @Inject etc??

Now that one can be debated for aeons. Strictly speaking those annotations are dependencies on your DI-Framework. But since those get standardized they become more of a Dependency to your language (which you can't avoid without getting into an infinite recursion and gathering lots of experience in language design). Dependencies on Annotations, which by definition can't contain any implementation aren't much of a problem, and I personally am fine with having them in my code.

What I don't see is what is the difference(implementation) from n-layer structure.

An onion structure is a specific variation of the rather general term of an n-layer architecture.