1

Trying to understand onion architecture. As I understand it, there is different opinions about the names of the layers.
In this post I refer to the layers as: infrastructure -> api -> domain -> core.

The core concept is, as I understood it, that the outer layers can know about the inner layers, but that the inner can not know about the outer.

Question

The question that appears to me is how to handle dependencies. I illustrated in the example below my assumption. The question is if this assumption is correct, which I make a point in the end why I believe it is not.

Example

A db query. The domain has an aggregate root with a repository that retrieves data from a gateway. The gateway is an interface that a driver adapter is implementing. The adapter is located in the infrastructure, sense it has to have access to the driver (I read however that adapters should go in the api). So the repository must be injected with a gateway, that is an adapter, by the controller through the aggregate it uses. Meaning that the controller must be injected with a Gateway.

Assumption

  • Domain
    • Aggregate
    • Repository -> returns an entity, located in the core, along with value objects etc..
    • Gateway (interface)
  • Api
    • Controller -> injected with a gateway by the infrastructure
  • Infrastructure
    • Driver
    • Adapter (implements Gateway)

1.) This means that the domain can never know the database structure.

2.) If we have multiple persistence engines, which I do in my case, the controller can't know which one of the adapters to use, sense it has no knowledge of anything but the gateway. So the infrastructure needs to have knowledge of which adapter to inject where and when (this seems very strange to me)

Improve this question
5
  • I wouldn't recommend putting your database in the middle of your architecture. The database is a detail, not a major architectural component. It certainly doesn't belong in your Domain logic. The domain logic should mostly contain plain old classes with no external dependencies.
    – RubberDuck
    Jun 22, 2016 at 22:13
  • @RubberDuck can you explain how you mean that the database is in the middle here? Onion design, referenced, defines the database in the infrastructure that lays in the outer layer, not in the center. As I described it, I keep the domain layer decoupled from the infrastructure. and the api, it will only depend on ValueObjects from the core. So I don't understand your comment.
    – superhero
    Jun 23, 2016 at 8:37
  • @ErikLandvall what exactly have you been reading? this?
    – candied_orange
    Jul 22, 2016 at 22:41
  • @CandiedOrange I have a better understanding about it today then when I posted this question. As I see it today, I understand that the implementations of the domain all goes in the infrastructure, but I'm still a bit lost in understanding the complete concept. I'm slowly adapting my code with this in mind however, so if you like to shine some light on it, I would love to read it..
    – superhero
    Jul 25, 2016 at 8:25
  • @CandiedOrange What I have been reading is a lot imo, also some youtube videos.. I think most of the misunderstanding comes from a youtuber that I don't remember the name or channel of now..
    – superhero
    Jul 25, 2016 at 8:31

1 Answer 1

Reset to default
1

In you Assumptions you do not distinguish between infrastructureInterfaces and infrastructureImplementation

I see these layers

  • infrastructureInterfaces -> api -> domain -> core -> app
  • infrastructureInterfaces -> infrastructureImplementation -> app

The app knows every thing and is responsible to instatiate infrastructureInterfaces with infrastructureImplementation.

Domain and Api only need to know the repositoryInterface while the app initialises Domain and Api with a concrete RepositoryImplementation

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.