This 3rd post in the series about moving from an architecture where Domain Model code depends on to Data Access code to an architecture where that dependency is reversed shows how that can be accomplished using Dependency Inversion.
To recap the situation we come from is this:
and we want to get to this:
Before While the dependency points from the Domain Model to the Data Access component we might have code like this in the Domain Model:
which depends on this interface in the Data Access Component:
"Abstractions should not depend upon details. Details should depend upon abstractions"
This tells us that the Data Access code - a detailed level - should not depend on the Domain Model - an abstraction - but vice versa. In other words the Domain Model component should be changed to include this interface
which should be used by the Domain Model code:
That new DomainModel.WishListRepository interface should be defined in the Domain Model and implemented in the Data Access component:
And that inverts the dependency.
Conclusion We have inverted the dependency between Domain Model and Data Access, such that the Data Access component now depends on the Domain Model, while the Domain Model has one dependency less. As a side effect the type WishListDTO disappeared, so we end with less code and a better separation of concerns.
Previous Topic
