How to inject an abstract factory into an entity's method?

Question

I have an Order entity with a refund() method that uses an abstract factory refundStrategyFactory to create the appropriate refund strategy at run-time:

public class Order extends Entity{

    public void refund(Employee emp, Quantity qty, IRefundStrategyFactory refundStartegyFactory){
        //use the abstract factory to determine the appropriate strategy at run-time.
    }
}

I'm trying to use dependency injection and have IRefundStrategyFactory injected automatically into the refund() method, but I couldn't find a way to achieve this.

I'm not using the constructor injection because Order is an entity and we shouldn't inject services into entities unless it's going to be used temporarily as in the refund method. This is better explained by Misko Hevery's blog post To “new” or not to “new”…:

It is OK for Newable to know about Injectable. What is not OK is for the Newable to have a field reference to Injectable.

A similar answer by Mark Seemann to a related question also advocates the same idea.

Bonus point, Aren't I exposing the internals of the refund() method by exposing its dependency on IRefundStrategyFactory? Should I sacrifice unit testing in isolation and create the factory inside the method itself?

Answer 1

Well ideally your domain model should be free infrastructure concerns and IOC is a infrastructure concern, it is recommended that the domain model be simple POJO's. So I would not inject beans into my domain model.

In this case i think you should have a application service which gets injected the factory class and it then just passes the factory class as a parameter to your Order class.

Does the factory class use some information from the Order class to decide which kind of strategy class to instantiate ?

Bonus point, Aren't I exposing the internals of the refund() method by exposing its dependency on IRefundStrategyFactory?

I am not sure if there is such a thing as exposing the internals of a method, This concept fits more naturally with "exposing internals of a class", A method does some action and to do so it might need some information from the outside world, we could debate on how to pass in that information and whether that one method is doing too much or not ? ... But i cannot reason on whether a method "exposes its implementation", maybe you should elaborate on what you meant by that point

Answer 2

I'd solve this by starting a refund process with eventual consistency, where you trigger a Refund action. The listeners to this action and it's events would then do their own tasks, i.e. refund the cost of the goods, restock the items, etc. Alternatively you could just do this atomically in an application service that triggers several domain services, one after another, passing in the Order item:

FinancialService.RefundOrderGoods(myOrder);
StockService.RestockOrderItems(myOrder);
...

I'd avoid adding any services or repositories into your entities.

Answer 3

Your main problem is that you can't "injected automatically into the refund() method", but IMO that isn't a problem at all, since you can simply pass on the dependency onto the method but still use constructor injection in the service that calls this method:

public class ApplyRefundHandler : ICommandHandler<ApplyRefund>
{
    private readonly IRefundStrategyFactory refundStartegyFactory;
    private readonly IRepository<Order> orderRepository;
    private readonly IRepository<Employee> employeeRepository;

    public ApplyRefundHandler(IRefundStrategyFactory refundStartegyFactory,
        IRepository<Order> orderRepository,
        IRepository<Employee> employeeRepository)
    {
        this.refundStartegyFactory = refundStartegyFactory;
        this.orderRepository = orderRepository;
        this.employeeRepository = employeeRepository;
    }

    public void Handle(ApplyRefund command)
    {
        Order order = this.orderRepository.GetById(command.OrderId);
        Employee employee = this.employeeRepository.GetById(command.EmployeeId);
        order.refund(employee, command.Quantity, this.refundStartegyFactory);
    }
}

Aren't I exposing the internals of the refund() method by exposing its dependency on IRefundStrategyFactory? Should I sacrifice unit testing in isolation and create the factory inside the method itself?

Yes you are, but in the same time you are probably violating the Single Responsibility Principle by adding a lot of business logic in the Order class. If you hide the abstractions, it means you need to inject them into the constructor and you will probably find out quickly that your Order class gets a lot of dependencies. So instead you can view the Order's methods as a Single Responsibility (a class in disguise) that has little to no relationships with the other methods in that class, and in that case it makes sense to pass in its dependencies into that method.

As a side node, please be aware that factory abstractions, like your IRefundStrategyFactory are usually not good abstractions. You should consider removing it, as described in detail here.