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"