Open gpbPiazza opened 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.
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?
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).
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.
Why, your
Infrastructure
layer is making reference to the models of the domain onrepositories
? Should theInfrastructure
never points upwards on the layered architecture? For exempla here yourLocationRepositoryJPA
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?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.