DDD and Dependency Injection

Question

I'm currently trying to 'marry' the DDD pattern with dependency injection (using Ninject), but I feel I'm breaking fundamental principles by doing so.

I've have a console application that hosts the NancyFX web framework on top of OWIN to provide a configuration interface. My project structure is as following:

Infrastructure
    - Infrastructure.Core
        - Repositories
        - Mappings
    - Infrastructure.Media
        - Media Services

Core
    - Logging & Exception-Handling intercaces

Domain
    - Entities
    - Repositories
    - Services

App
    - Main application

Web
    - Web Frontend (Nancy Modules, Models etc.)

Since I'm DIying (heh...) all over the place (injecting contexts into repositories, resolving singleton services...), I've created a static class in my App project that creates a IKernel instance and registers all the dependencies at the application startup.

I've got some repositories that will be accessed in Nancy Modules and self hosted Web API controllers, now the first problem I face is when I would like to register the repositories in a 'per request' lifetime: IKernel.Bind().PerRequest() is only available in the Ninject.Web.Common package which depends on Microsoft.Web.Infrastructure etc.. etc.. I'm ending up creating dependencies to web specific packages in a component that basically knows nothing about my web framework or the API (except for configuring OWIN).

Additionally, by binding domain repository & services interfaces to concrete implementations from the infrastructure layer, I make my application depending on the implementations, which doesn't really feel right.

How could I solve those issues?

Answer 1

Have you heard of Composition Root? You register stuff to specific implementations only in the top most project, the web app for example. Everywhere else you code against interfaces.

Sounds like you already invented this by yourself and I can't really feel the problem - since this is the top most project to reference all the stuff, including web, owins, ninjects and others, there really should be no problem here.

My advice would be to never use singletons. Instead, have factories or local Dependency Resolvers. A resolver is a part of local infrastructure that serves as the hub that creates services in an isolated subsystem. The resolver can be safely used by its surroundings, it doesn't reference anything but it has a configurable provider that again is set up in the Composition Root.

This way, if the resolver uses a specific implementation or even specific DI container, all it set up in the top most project.