Architecture: dependency injection, build assemblies, implementation hiding

I am working on a personal project that, in addition to doing something useful for myself, I tried to use as a way to continue searching and learning architectural lessons. One such lesson appeared as a Kodiak bear in the middle of a bike lane and I struggled with it very hard.

The problem is essentially an amalgam of problems at the intersection of dependency injection, build failure, and implementation hiding (i.e. implementing my public interfaces using inner classes).

In my work, I usually find that different layers of the application store their own interfaces, which they publicly expose, but internally implement. Each DI code in an assembly registers an inner class with a public interface. This method prevents assembly assemblies from appearing by an instance of the implementation class. However, some of the books I read while creating this solution have spoken out against it. The main things that conflict with my previous thinking have to do with the root of the DI composition and where to maintain interfaces for a given implementation. If I move the dependency registration to one, the global root composition (as Mark Semann points out), I can walk away from each assembly so that it does its own dependency registrations. However, the disadvantage is thatthat implementation classes should be public (allowing any assembly to create them). In terms of decoupling assemblies, Martin Fowler instructs to put interfaces in a project with code that uses the interface, not the one that implements it. An example is the diagram he provided and, for comparison, a diagram for how I usually implement the same solution (ok, it's not exactly the same, kindly focus on the arrows and note the borders instead of composition shooter).it's not exactly the same, kindly focus on the arrows and note the borders instead of the composition arrows).it's not quite the same, kindly focus on the arrows and note the borders instead of the composition arrows).

Martin Style

What i used to see

I immediately saw the advantage in Martin's diagram that it allows the lower assemblies to be replaced with others, given that it has a class that implements the interface in the layer above it. However, I've also seen this seemingly major flaw: if you want to change the build location at the top level, you essentially "steal" the interface that the bottom level implements.

After thinking about it a bit, I decided that the best way to be completely decoupled in both directions is to have interfaces that define the contract between layers in their own assemblies. Consider this updated diagram:

Is it nutty? Right? For me, this seems to solve the interface segregation issue. However, it does not solve the problem of not being able to hide an implementation class as internal. Is there something sane that can be done there? Should I not worry about this?

One solution I'm playing with in my head is for each layer to implement the proxy layer interface twice; once with the open class and once with the inner class. So the public class can just wrap / decorate the inner class like:

Some code might look like this:

namespace MechanismProxy // Simulates Mechanism Proxy Assembly
{
    public interface IMechanism
    {
        void DoStuff();
    }
}

namespace MechanismImpl // Simulates Mechanism Assembly
{
    using MechanismProxy;

    // This class would be registered to IMechanism in the DI container
    public class Mechanism : IMechanism
    {
        private readonly IMechanism _internalMechanism = new InternalMechanism();

        public void DoStuff()
        {
            _internalMechanism.DoStuff();
        }
    }

    internal class InternalMechanism : IMechanism
    {
        public void DoStuff()
        {
            // Do whatever
        }
    }
}

      

        
        
        
      

    

... of course, I still have to solve some problems related to installing the constructor and passing the dependencies injected into the public class into the inner one. There's also a problem that external assemblies can possibly create a new public transport mechanism ... I need a way to ensure that only the DI container can do this ... I suppose if I could figure it out I wouldn't even need an internal version ... Anyway, if anyone can help me understand how to overcome these architectural problems, it would be much appreciated.