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

Question

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?

Answer 1

IMO doing outside-in TDD isn't a valid enough reason to introduce the kind of "factory service" you mentioned.

• If constructing a domain object involves complicated logic (such as composing it from multiple different sources), then it might be worth it to put that logic in a separate Factory class. You can mock that class in tests if you want to, but no need for an additional creation façade.

• If it is simple value-to-field assignment, the logic is probably within the reasonable responsibility of the object itself. Don't try to mock it. Just because you don't mock it doesn't mean it breaks outside-in TDD. Newing up an object you need, at any step of an outside-in TDD process, is legit.

all of your service layer tests are being failed as long as you are not implemented the static factory method

But adding an extra layer of "Factory Service" doesn't add any value and isn't the solution. It just shows that your Application Service is able to talk to a layer that didn't exist before.

Implementing a minimal Entity and its constructor is small enough work to allow you to pass your service layer tests with roughly the same, or even less, effort than writing a creation interface and mocking it.

Besides, the typical assertion in outside-in tests when you're creating something is to spy on a Repository or data access object to know if the object received the new thing to store. This defuses the "inner construction method vs dedicated factory interface" debate with regard to testing, because that's not where you exercise your tests.

As a side note, some people recommend to avoid mocking domain objects altogether (a.k.a. mock only at architecturally significant boundaries).

Answer 2

makes the unit testing painful

Part of the motivation for "test first" development is the heuristic that awkward tests imply awkward interfaces -- if writing the test clients is painful, that's a hint (but not necessarily a promise) that writing the production clients will also be painful.

Is it ok to create a factory service per aggregate root with a factory method per aggregate/value object?

You probably mean "with a factory method per entity/value object" -- we normally have one or more entities per aggregate, but nesting multiple aggregates isn't a common pattern.

And yes, if you think that interface is easier to work with, then fine, go right ahead.

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

You might get a bit more separation by using role interfaces to describe the different parts of the API. For example, if we are writing a unit test about CEO's, then we don't care much about the capability to create other entities. So we might prefer

interface ICreateCEO {
    CEO createCEO(...);
}

class CompanyFactory implements ICreateCEO ... {
    CEO createCEO(...);
}

But that's definitely "might", rather than "should" -- the "extra" interfaces aren't free to maintain, so you want to be sure you are getting compensation somewhere.

Answer 3

Static is almost always a bad word. Try not to type it.

You should be able to allow injection and also have a default factory, since you don't mind coupling a factory to your aggregate type

public class Service
{
    public Service(IFactory fac = new MyFactory()) {...}
}

Now you can skip injection in you appplication and inject a mock in your tests