Architecture: Dependency Injection, Loosely Coupled Assemblies, Implementation Hiding

Question

I've been working on a personal project which, beyond just making something useful for myself, I've tried to use as a way to continue finding and learning architectural lessons. One such lesson has appeared like a Kodiak bear in the middle of a bike path and I've been struggling quite mightily with it.

The problem is essentially an amalgam of issues at the intersection of dependency injection, assembly decoupling and implementation hiding (that is, implementing my public interfaces using internal classes).

At my jobs, I've typically found that various layers of an application hold their own interfaces which they publicly expose, but internally implement. Each assembly's DI code registers the internal class to the public interface. This technique prevents outside assemblies from newing-up an instance of the implementation class. However, some books I've been reading while building this solution have spoken against this. The main things that conflict with my previous thinking have to do with the DI composition root and where one should keep the interfaces for a given implementation. If I move dependency registration to a single, global composition root (as Mark Seemann suggests), then I can get away from each assembly having to run its own dependency registrations. However, the downside is that the implementation classes have to be public (allowing any assembly to instantiate them). As for decoupling assemblies, Martin Fowler instructs to put interfaces in the project with the code that uses the interface, not the one that implements it. As an example, here is a diagram he provided, and, for contrast, a diagram for how I would normally implement the same solution (okay, these aren't quite the same; kindly focus on the arrows and notice when implementation arrows cross assembly boundaries instead of composition arrows).

Martin Style

What I've normally seen

I immediately saw the advantage in Martin's diagram, that it allows the lower assemblies to be swapped out for another, given that it has a class that implements the interface in the layer above it. However, I also saw this seemingly major disadvantage: If you want to swap out the assembly from an upper layer, you essentially "steal" the interface away that the lower layer is implementing.

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

Is this nutty? Is it right on? To me, it seems like this solves the problem of interface segregation. It doesn't, however, solve the problem of not being able to hide the implementation class as internal. Is there anything reasonable that can be done there? Should I not be worried about this?

One solution that I'm toying around with in my head is to have each layer implement the proxy layer's interface twice; once with a public class and once with an internal class. This way, the public class could merely wrap/decorate the internal class, like this:

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'd still have to address some issues regarding constructor injection and passing the dependencies injected into the public class to the internal one. There's also the problem that outside assemblies could possibly new-up the public Mechanism... I would need a way to ensure only the DI container can do that... I suppose if I could figure that out, I wouldn't even need the internal version. Anyway, if anyone can help me understand how to overcome these architectural problems, it would be mightily appreciated.

Answer 1

However, the downside is that the implementation classes have to be public (allowing any assembly to instantiate them).

Unless you are building a reusable library (that gets published on NuGet and gets used by other code bases you have no control over), there is typically no reason to make classes internal. Especially since you program to interfaces, the only place in the application that depends on those classes is the Composition Root.

Also note that, in case you move the abstractions to a different library, and let both the consuming and the implementing assembly depend on that assembly, those assemblies don't have to depend on each other. This means that it doesn't matter at all whether those classes are public or internal.

This level of separation (placing the interfaces in an assembly of its own) however is hardly ever needed. In the end it's all about the required granularity during deployment and the size of the application.

As for decoupling assemblies, Martin Fowler instructs to put interfaces in the project with the code that uses the interface, not the one that implements it.

This is the Dependency Inversion Principle, which states:

In a direct application of dependency inversion, the abstracts are owned by the upper/policy layers

Answer 2

However, the downside is that the implementation classes have to be public (allowing any assembly to instantiate them).

That doesn't sound like a downside. Implementation classes, that are bound to abstractions in your Composition Root, could probably be used in an explicit way somewhere else for some other reasons. I don't see any benefit from hiding them.

I would need a way to ensure only the DI container can do that...

No, you don't.

Your confusion probably stems from the fact that you think of the DI and Composition Root like there is a container behind, for sure.

In fact, however, the infrastructure could be completely "container-agnostic" in a sense that you still have your dependencies injected but you don't think of "how". A Composition Root that uses a container is your choice, as good choice as possible another Composition Root where you manually compose dependencies. In other words, the Composition Root could be the only place in your code that is aware of a DI container, if any is used. Your code is built agaist the idea of Dependency Inversion, not the idea of Dependency Inversion container.

A short tutorial of mine can possibly shed some light here

http://www.wiktorzychla.com/2016/01/di-factories-and-composition-root.html

Answer 3

This is a somewhat opinion based topic, but since you asked, I'll give mine.

Your focus on creating as many assemblies as possible to be as flexible as possible is very theoretical and you have to weigh the practical value vs costs. Don't forget that assemblies are only a container for compiled code. They become mostly relevant only when you look at the processes for developing, building and deploying/delivering them. So you have to ask a lot more questions before you can make a good decision on how exactly to split up the code into assemblies.

So here a few examples of questions I'd ask beforehand:

Does it make sense from your application domain to split up the assemblies in this way (e.g. will you really need to swap out assemblies)?

Will you have separate teams in place for developing those?

What will the scope be in terms of size (both LOC and team sizes)?

Is it required to protect the implementation from being available/visible? E.g. are those external interfaces or internal?

Do you really need to rely on assemblies as a mechanism to enforce your architectural separation? Or are there other, better measures (e.g. code reviews, code checkers, etc.)?

Will your calls really only happen between assemblies or will you need remote calls at some point?

Do you have to use private assemblies?

Will sealed classes help instead enforcing your architecture?

For a very general view, leaving these additional factors out, I would side with Martin Fowler's diagram, because that is just the standard way of how to provide/use interfaces. If your answers to the questions indicate additional value by further splitting up/protecting the code that may be fine, too. But you'd have to tell us more about your application domain and you'd have to be able to justify it well.

So in a way you are confronted with two old wisdoms:

1. Architecture tends to follow organizational setups.
2. It is very easy to over-engineer (over-complicate) architectures but it is very hard to design them as simple as possible. Simple is most of the time better.

When coming up with an architecture you want to consider those factors upfront otherwise they'll come and haunt you later in the form of technical debt.