Dependency between Domain and Data layer

[BattleShipPark]

Hi, I read #136 about dependency between Domain and Data layer. I understood Data layer is the implementation of Domain layer and not the most inner circle.
Especially, I found Repository Inferface is in Domain layer in the diagram, which means Data layer should implement Domain layer.

However, people including me are confused in such a concept. It is not easy to ordinary people.
Then what about this?

It means, Data layer is not the implementation of Domain layer and the direction of dependency is only one way, Presentation to Data, left to right.

My idea can be an alternative among many implementations? Or it has a serious problem?

[mjohenneken]

In short i would say boundaries in the data layer is the style of 3 layered architecture. Boundaries in the domain is more the style of Clean Architecture because we follow the depencency rule.

The biggest Point should be that the domain layer uses boundaries(some kind of well defined interface) to abstract between what is available and how it is implemented.

Where you put your interface ends up being a decision made on a project basis e.g. what was implemented first, do i use seperate gradle modules for each layer.

[BattleShipPark]

@mjohenneken Your answer helped to understand the difference between Clean Architecture and what I imagined. Clean Architecture is much more difficult than I thought :)
Thanks.

[pkliang]

Please check #245 . Domain layer should not have any dependency on outer layers, data layer sits at framework and drivers layer.

This follows the Dependency Inversion principle

High-level components and low-level components are distributed into separate packages/libraries, where the interfaces defining the behavior/services required by the high-level component are owned by, and exist within the high-level component's library. The implementation of the high-level component's interface by the low level component requires that the low-level component package depend upon the high-level component for compilation, thus inverting the conventional dependency relationship.

[PasqualeLivecchi]

Here is how everything is laid out, according to Uncle Bobs clean architecture lecture. The part thats confusing is differentiating what people mean by 'data layer'. Do they mean how the data is stored within the apps database? Or do they mean how the app retrieves its data from an outside source? According to the link from uncle bob, it means the place where data is stored so it would be better to call it the 'database layer'.

The picture provided by the readme file is confusing. What it should be is Presentation Layer IMPLEMENTS or DEPENDS on the OUTPUT boundary interfaces while the Database Layer IMPLEMENTS or DEPENDS on the INPUT boundary interfaces. The interactor ALSO can DEPEND or IMPLEMENT BOTH boundary interfaces because the boundary interfaces are on the domain layer. The interactor is all your USE CASES and is what carries out whatever the app is supposed to do, the entities are not the focus of the domain layer, the interactor is. The picture provided on the readme page makes it seem like the interactors can only work with the presenter layer and the entities, when really the interactors should be the center, and 2 seperate boundary interfaces should be on the edges.

This can also get confusing when you incorporate dependency injection because then it becomes just 1 boundary interface(that would makes up a bunch of entity repos that might confuse people further because the database has repos too) and that gets injected by the database layer and presentation layer. I could be wrong though about the DI stuff, but the other stuff is how uncle bob interprets it.

[mishkaowner]

@dancoyle21 What do you mean by

What it should be is Presentation Layer IMPLEMENTS or DEPENDS on the OUTPUT boundary interfaces while the Database Layer IMPLEMENTS or DEPENDS on the INPUT boundary interfaces. The interactor ALSO can DEPEND or IMPLEMENT BOTH boundary interfaces because the boundary interfaces are on the domain layer.

You are just simply wrong. Look at the diagram again. Open arrows and line arrows both indicate different implementation relationships.