Correct design using dependency inversion principle across modules?
I understand dependency inversion when working inside a single module, but I would like to also apply it when I have a cross-module dependency. In the following diagrams I have an existing application and I need to implement some new requirements for reference data services. I thought I will create a new jar (potentially a stand-alone service in the future). The first figure shows the normal way I have approached such things in the past. The referencedataservices jar has an interface which the app will use to invoke it.
The second figure shows my attempt to use DIP, the app now owns its abstraction so it is not subject to change just because the reference data service changes. This seems to be a wrong design though, because it creates a circular dependency. MyApp depends on referencedataservices jar, and referencedataservices jar depends on MyApp.
So the third figure gets back to the more normal dependency by creating an extra layer of abstraction. Am I right? Or is this really not what DIP was intended for? Interested in hearing about other approaches or advice.
, 
The second example is on the right track by separating the implementation from its abstraction. To achieve modularity, a concrete class should not be in the same package (module) as its abstract interface.
The fault in the second example is that the client owns the abstraction, while the service owns the implementation. These two roles must be reversed: services own interfaces; clients own implementations. In this way, the service presents a contract (API) for the client to implement. The service guarantees interaction with any client that adheres to its API. In terms of dependency inversion, the client injects a dependency into the service.
Kirk K. is something of an authority on modularity in Java. He had a blog that eventually turned into a book on the subject. His blog seems to be missing at the moment, but I was able to find it in the Wayback Machine. I think you would be particularly interested in the four-part series titled Applied Modularity. In terms of other approaches or alternatives to DIP, take a look at Fun With Modules, which covers three of them.
- Does the Dependency Inversion Principle apply within application layers?
- How to make Django Manager and Model's interactions follow the Open/Closed Principle?
- Where to instantiate my classes and still adhere to SRP
- Abstract class design for a menu system in Unity: Static vs Dynamic Menus
- What is an example of the Liskov Substitution Principle?
- Does an additional service class violates Single Responsibility Principle?
- How could I use DbContext in repository for implementing dependency inversion principle in ASP.NET Core 8.0 MVC
- In SOLID, what is the distinction between SRP and ISP? (Single Responsibility Principle and Interface Segregation Principle)
- Private props return unmodified or losing values within the class inside scope of child class method
- How to implement SOLID principles into an existing project
- What is the dependency inversion principle and why is it important?
- How does the SOLID open/closed principle fit in with Dependency Injection and dependency inversion
- Does the Single Responsibility Principle work in OOP?
- Are interfaces required for the Dependency Inversion Principle?
- SOLID principles implementation for C
- Managing controllers for identical entity structures?
- Dealing with a Factory that uses both a Strategy and Repository
- Composition over Inheritance - code duplication
- Does composition violate the D in SOLID?
- Single Responsibility Principle(SRP) and my Service Class
- C# compile error trying to apply Liskov Substitution Principle
- Dependency Inversion Principle: is a low level module allowed to have a hidden reference to another low level module?
- Is it possible to strictly comply with Liskov's principle with interfaces?
- How to extend a class stored in the database without big consequences for the whole system?
- api_view['POST', 'GET'] against SOLID principles?
- How to apply the principle of dependency inversion in the provider?
- Liskov substitution principle - example
- Liskov Substitution Principle: Confusion about additional Functionalities of sub types
- How do I have a method return one of almost the same classes case to case?
- Inject multiples interfaces is against SOLID?