How does "Composition Root" DI apply to Domain Driven Design?

Question

I'm confused about applying the "Composition Root" (CR) to create aggregates in DDD. Seemann (2012) defines CR as a "(preferably) unique location ... where modules are composed". He argues for composing object graphs inside CR, near the application's entry point, and warns against the temptation to compose "classes a little at a time to create small subsystems".

An aggregate in DDD appears like such a subsystem -- a (sub) graph with entities and value objects. Evans (2004) and other DDD texts (Vernon 2013, Ghosh 2017) recommend constructing aggregates inside factories, located in the domain layer, "near" the aggregate (eg a factory method on the aggregate root) or as standalone services. This seems to contradict the CR approach.

The question is whether and how the CR and Factory approaches should be combined in DDD. For instance,

• A CR is put inside the domain layer, rather than at the app's entry. Possibly, the factories are pooled to this single location
  OR
• The benefits of CR (eg, the "ability to intercept subsystems to modify their behavior"; Seemann) are irrelevant to DDD.
• CR DI does not apply to creation of aggregates but works at a higher granularity level (eg injection of services). Then CR methods use factories to construct aggregates, to place them on the object graph.

References
M. Seemann, 2012, "Dependency Injection in .NET"
E. Evans, 2004, "Domain-Driven Design"
V. Vernon, 2013, "Implementing Domain-Driven Design"
D. Ghosh, 2017, "Functional and Reactive Domain Modeling"

Answer 1

Typically, the composition root is about satisfying the dependencies of various modules that make up a process/application.

When Evans described DDD in the blue book, he was working in the context of a three tier architecture. You can think of the tiers as being modules - an application module, which knows about the interface(s) of the domain module but not the implementations, and a domain module that knows the interface of the persistence module, but not its implementation.

Because the coupling between modules is interface, rather than implementation, we can replace one module with another that implements the same interface, and it should all "just work".

The role of the composition root is the selection of implementations, and the wiring together of the dependency graph. So the composition root knows enough about the specific implementations to instantiate them, passing the appropriate implementation of each.

In architectures where constructor injection is favored, this might look like

PersistenceAPI persistence = new PersistenceModule(...)
DomainAPI domain = new DomainModule(persistence, ...)
Application app = new Application(domain, ...)

app.run()

Broadly, the modules describe their dependencies -- capabilities that they need but don't implement for themselves, and the composition root does the work of introducing capability consumers with capability producers.

An important thing to notice here; the pattern is deferring the binding of the consumer to a specific capability provider -- instead of forcing a choice when we build a module, we delay that choice until we build the root (or, with some additional work/assistance from DI frameworks, we can defer the choice until run time).

So for DDD, the answer is relatively simple: you use the composition root approach in those parts of your solution where you derive business value from deferring the binding of a consumer to a specific implementation.

Example: one way of persisting domain state is by writing data into an RDMBS, possibly with the help of an ORM. Another way would be to serialize that state into a document written to a document store. That might be a raw serialization of the object, or it might instead be in the form of a message/memento which is less coupled to a specific in memory representation.

Most of the app shouldn't need to care which of these choices that you make; so there can be business value in creating a seam that allows you to change this decision.

The composition root pattern gives you an element where the single responsibility is stitching these seams together into a working application.

Answer 2

This is how I'd approach the problem, based on the excellent answer and comments given.

There's a similarity between the Composition Root and an Aggregate Root: the former composes the whole application graph, and the latter contains the local object sub-graph for an Aggregate (@RobertHarvey). Hence, DI via a Composition Root can be used to compose program layers and modules within layers, and to swap interface implementations as required (@VoiceOfUnreason).

A factory "near" the Aggregate Root can be used at a finer granularity, to construct instances of a particular aggregate. Thus the knowledge is kept local eg, of how to construct value objects to populate the aggregate and how to validate it with specific rules. Also, for an aggregate representing a well-formed domain concept, no flexible implementations of internal members may be necessary. Still, a Composition Root DI may be used to inject aggregate factories into clients (@Euphoric).

In summary, I'd attempt a hierarchical approach, mixing higher-level DI from a Composition Root module with lower-level aggregate factories.