480834 (1) [Avatar] Offline
#1
Hello,

I have read the first edition and I really appreciate it. Now I want to put what I learned into practice but while thinking about my architecture I realized I still have some misunderstandings. In the following I am referring to the RightCommerce solution.

In the second edition you wrote :
There is however another interesting part of the Dependency Inversion Principle that many developer don’t know about. Not only does the principle prescribe loose coupling, it states that Abstractions should be owned by the layer using the Abstraction.

In this context, 'owned' means that the consuming layer is in control over the shape of the Abstraction. It should be able to define the Abstraction in a way that benefits itself the most.

Then if we follow this rule we should move IProductService from the Domain to the Web project. Of course it's not possible because it is creating a circular reference. So this rule doesn't sound right to me.

Thanks.
Steven van Deursen (40) [Avatar] Offline
#2
Your observation is correct. IProductService does violate the DIP. To fix this violation there are a few options, such as moving IProductService to the Presentation Layer, or moving this interface to a separate project that only contains Domain Layer abstractions.

Moving the interface to the Presentation Layer would obviously cause problems, because it would make the Domain Layer specific to the used presentation technology, which disallows it to be reused. Besides, as long as the Composition Root would be placed in the same assembly as the Presentation Layer, a cyclic dependency between the assemblies would exist, as you so rightfully point out.

Moving the interface to a separate "interfaces" project would be the most appropriate solution. We however made the pragmatic decision to put the interface in the Domain Layer project itself, because this would simplify the discussion within the chapter.

What we omitted however was an explanation about this pragmatic decision, which is something we should add to chapter 3.


Thank you for reporting this.
mathys (3) [Avatar] Offline
#3
isn't it more or less an issue due to fact that IProductService only exists for testing purposes and therefore a violation of the reused abstraction principle(RAP)?

It's not likely you will have more than one IProductService in your codebase anyway because this is the logic part of your application.
Steven van Deursen (40) [Avatar] Offline
#4
Whether or not IProductService violates the RAP depends on whether we will have other implementations. In later chapters we show how to add cross-cutting concerns using Decorators on top of IProductService. At that point, IProductService stops violating the RAP.

IProductService serves other purposes than just enabling testing, and this basically comes back to the advantages of DI, as discussed in chapter 1—testability is just one of them.