Can Aggregate Root Factory create the root, and it's internal classes?

Question

Currently, my aggregates and value objects have protected constructors and almost all of them are being created by static factory methods inside the aggregate with descriptive names. It creates a nice DSL and pretty encapsulated model but makes the unit testing painful (if the domain model creation fails, the service/command handler will be marked as failed as well). Introducing factory methods on the other hand for each entity, and value object forces me to inject a factory interface per entity/value object into the service.

Is it ok to create a factory service per aggregate root with a factory method per entity/value object? Here's an example of a factory service which creates a company aggregate root, and it's internal entities/VOs:

public class CompanyFactory : ICompanyAggregateRootFactory
{
    public Company CreateCompany(...){}
    public Employee CreateEmployee(...){}
    public CEO CreateCEO(...){}
    ....

}

Is there any other way which enforces the same level of encapsulation and DSL clarity without making the unit tests depending on one another?

Answer 1

The blue book has a chapter about factories. And yes it is totally ok to create a factory for your aggregate root. The internal implementation of this factory doesn't matter a lot. You can use other factories for value objects or any other way. I have one suggestion: I don't know a lot about your domain but I thing the employee should be a separate aggregate. And CEO is actually an employee so maybe you should rethink this design.