One of the first questions I had once I decided to hide internal state in my domain was how to code decisions paths based upon the current state of the system.

CQRS allows the “C” (command) side to become a client of the “R” (reporting) side, so it seemed logical to consume something like my web reporting model within my Domain Services that sit on top of my different domain packages to coordinate affairs. This got some decent mileage, but soon I realized that needless complexity had convoluted the answers to the questions these services are asking. This is the first smell of this kind of tight coupling so I knew I needed to clean up.

I was simply violating coding to interface even though I was consuming interfaces (repository interfaces from my web reporting model) in my services. In other words, I subtly let my reporting repositories lose their focus.

To alleviate this, I created a simple State.Interfaces package and then hid the fact that the state is coming from my web model in a separate package.

This makes things far simpler and, of course, looser coupled.