I am using DDD for 3 of my applications that use the same domain layer (domain services) via 3 different application (workflow) services. Infrastructure & UI layer don't have access of domain services. I'm also passing all external dependencies like repository via domain service constructor. So, do I need to create interface on domain services? Note that I have defined interface for application services.
3
votes
An interface might help you with more granular testing, but if you don't need it, don't create it.
– JefClaes
@JefClaes, well that's the thing. I don't think (may be not realizing) domain service interface would help for even granular testing as the implementation of domain service would be concrete. In other words, the domain service business logic should not be swapped. Not only that but the only reason I see to create interface on application services is to mock it while creating unit test on controller (if we do!!). I would be much appreciate if anyone give me a reason to create interface for service.
– Parth Patel
I think you've covered the 2 main reasons, if you code to an interface and use DI, you can swap the class out for another and reduce the dependencies and it makes it possible/easier to unit test.
– Adrian Thompson Phillips
@ParthPatel Why are you looking for a reason? You can always extract an interface once you see a need for it.
– JefClaes
You are right. Actually, I was thinking this because my own object factory class had a limitation of auto detecting the object constructor's parameter types and couldn't resolve it from registered dependencies. I replaced factory class with StructureMap and now everything is fine. :-) This has changed the way I was thinking about DI.
– Parth Patel
