I'm in a situation where part of my system has a dependency on another module in the same system, but the modules themselves need to remain independently deployable, where the parts they depend on would be filled in with another implementation.
A module in this instance is the concept of a bunch of components that all contribute to servicing a business function. The system is also built in C#.
So, where I depend on another module, the source module defines an interface describing the functions it needs the dependent party module to implement. The contract types (domain model objects) are also interfaces for the dependent module.
Here is where it gets a bit hazy to me. The dependency inversion principle doesn't sit well in my head at this point. Both of those "modules" are of the same importance as each other. Which should define interfaces and force the other to reference it? I'm suspecting a 3rd project sitting between the modules that handles setting up the dependencies (probably a DI container). Should the entities in the modules be interfaced? They are simply bags of get/set (no DDD here).
Can anyone offer any guidance here?
Thanks in advance.
The project structure:
Module1.Interfaces IModuleOneServices Module1.Models ModuleOneDataObject Module1 Module1 implements IModuleOneServices Module2.Interfaces IModuleTwoServices Module2.Models ModuleTwoDataObject - has property of type ModuleOneDataObject Module2 Module2 implements IModuleTwoServices depends on IModuleOneServices
Module2 needs to be deployable by itself, and remains compilable, and sometimes, run without a Module1 present at all.