Currently, my aggregates and value objects have protected constructors and some 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?
> why you find aggregate factory methods painful to unit test?
Because some of them are static (because of the protected constructors).