citerus / dddsample-core

This is the new home of the original DDD Sample app (previously hosted at sf.net)..
MIT License
4.91k stars 1.47k forks source link

Infrastructure layer depending on domain layer and interface declarations #127

Open gpbPiazza opened 5 months ago

gpbPiazza commented 5 months ago

Hi! I have some questions similar about the title and I hope that I can learn with you 😄, I am doing my own cargo-api and i have some interpretations different from yours.

  1. Why, your Infrastructure layer is making reference to the models of the domain on repositories? Should the Infrastructure never points upwards on the layered architecture? For exempla here your LocationRepositoryJPA know the types of the domain importing than, when I ready the book Eric makes clear you lower layers shouldn't have to point to the upper layers, so i thought that the infrastructure layer would have his own model declaration and in the domain layer we would translate that model with factories to the domain model, makes sense to you? Or I am caring too much about it, and it's ok to repositories knows the domain models?

  2. Why you are defining the interfaces where your domain depends on the domain layer? It's ok you define the interface of something (repository or a request to third party API) in the infrastructure layer and your domain depends on the interface declared on the infra and not the domain layer?

Thanks to make this repository public, I enjoyed a lot of reading and learning about your implementation.

11800222 commented 5 months ago

You can check out Chapter 4 in the book "Implementing Domain-Driven Design." They call this DIP (Dependency Inversion Principle), repositories in the domain better understand as an abstraction.

gpbPiazza commented 4 months ago

Thanks for the recommendation! I get it the idea about the question 2.

But I still in doubt about the question one, I read the chapter 6 again, and I didn't found anything talking about the domain types been referenced in the infra layer, the only thing that a found it was in the page 149 this quotes:

"Typically teams add a framework to the infrastructure layer to support the implementation of REPOSITORIES. In addition to the collaboration with the lower level infrastructure components, the REPOSITORY superclass might implement some basic queries, especially when a flexible query is being implemented. Unfortunately, with a type system such as Java's, this approach would force you to type returned objects as "Object," leaving the client to cast them to the REPOSITORY'S contained type. But of course, this will have to be done with queries that return collections anyway in Java."

So I can assume when Eric said this here, it's common only the repositories in the infra layer have reference from domain types?

mackapappa commented 4 months ago

I'm not sure if Evans mentions the dependency inversion principle (DIP) in his book, but instead describes the general dependencies between layers as goint from top to bottom. With DIP you can reverse the dependency between the domain layer and the infrastructure layer and this is done by declaring interfaces of infrastructure services in the domain layer. It's a common practise even though it's not mentioned in Evans book (but in other books, e.g. in "Implementing Domain-Driven Design." as mentioned above) and makes the domain layer the center of the layer-model (hexagonal architecture).