Question

Reading some interesting books on Domain driven design, one sample is as follows:

// Order
IOrderNumberService orderNumberService;
public void Accept()
{
    this.orderNumber = this.orderNumberService.GetNextAvailableNumber();
}

What is not shown in the above code, is that the OrderNumberService has been injected by a IoC framework. We don’t know the lifetime scope of the service object (a new service could be created for every injection, or a singleton injected every time).

For a service whose job it is to check the next useable number from a database, I see no state required and could safely (probably should) use a Singleton.

For this case, I don’t see the need to swap out this service and could just as easily call the singleton class concrete implementation directly OrderNumberService.GetNextAvailableNumber(), or at least if I needed to abstract with an interface I could always refactor later at that time.

Aside from abstracting the service interface from the implementation allowing easier testing, are there any other benefits of injecting the service?

I am wary of putting all the things I have read in to code just because they are cool – so at what point does abstraction create so many layers it makes code harder to read and what are the warning signs one should be mindful of?

Answer 1

Services don’t have state in DDD (Evans p. 107), no matter to which layer they do belong

When a significant process or transformation in the domain is not a
natural responsibility of an ENTITY or VALUE OBJECT, add an operation
to the model as a standalone interface declared as a SERVICE. Define
the interface in terms of language of the model and make sure the
operation name is part of the UBIQUITOUS LANGUAGE. Make the service
stateless

Using high level abstractions(interfaces) instead of the implementations(classes) is Dependency Inversion principle, and is not a Dependency Injection, Dependency Inversion is about relations of abstractions and implementations, while Dependency Injection is about removing hard coded dependencies – even if your field is an interface you still need to initialize it somehow, i.e assign a value to some class instance.

As for the technology for injecting the service instance, DDD is technology agnostic. If you think that using an IoC container makes things harder to read you may consider using Service Locator pattern instead, for the full reasoning see Martin J Fowler article on DI containers. But tbh DDD requires some sophisticated team(Evans mentioned it in some talks on infoq) so I think that it will be people who will be able to grasp IoC concepts, so Service Locator gives no big advantages here(except maybe if you are working is some limited environments like Android phones where the IoC framework is too heavyweight solution)

As for the infamous singleton pattern (implemented with a static class method) I don’t think that it is suitable at all because it’s not testable.

Also DDD promotes using lightweight frameworks (See Architectural Frameworks, Evans p. 74), and the contemporary frameworks (Spring, Fluent NHibernate, etc.) are developed with this in mind so they are actually designed to make working with POJO/POCO simpler (you can read more in a set of articles on framework design, written by the Fluent NHibernate architect Jeremy Miller http://codebetter.com/jeremymiller/2010/01/11/patterns-in-practice-a-retrospective/), many Spring projects, for example reference DDD directly. So it’s unlikely that the framework will force you to put a dependency in your code, or make it less readable – it will rather use reflection API to set the values, and will use some non-intrusive approach like XML or attributes(annotations) for the configuration.