The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

480834 (1) [Avatar] Offline

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.

Steven van Deursen (43) [Avatar] Offline
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
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 (43) [Avatar] Offline
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.