Notes From A Project Applying Domain-Driven Design, Event Sourcing and CQRS : Part 2

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.


Posted 05-06-2010 1:03 AM by Michael Nichols

[Advertisement]

Comments

Elliot wrote re: Notes From A Project Applying Domain-Driven Design, Event Sourcing and CQRS : Part 2
on 05-06-2010 5:23 AM

Hi Mike thanks for the post. One question, given you now have the dependency on your query services from your command services have you not lost your autonomy?

Michael Nichols wrote re: Notes From A Project Applying Domain-Driven Design, Event Sourcing and CQRS : Part 2
on 05-06-2010 1:02 PM

@Elliot

By 'autonomy' I presume you mean the separation between C & R. I would not say so, since the domain is simply acting as a client of the reporting store indirectly through a simple interface.

Does that answer your question?

Udi Dahan wrote re: Notes From A Project Applying Domain-Driven Design, Event Sourcing and CQRS : Part 2
on 05-07-2010 8:21 AM

In CQRS, the command-processing should not be dependent on the query side. Also, not all use cases in a system necessarily should be built with CQRS.

Mike wrote re: Notes From A Project Applying Domain-Driven Design, Event Sourcing and CQRS : Part 2
on 05-07-2010 11:09 AM

@Udi

Exactly .

I had some domain services that needed to get an aggregate root Id based on some criteria, so that is a 'report'. Where that info comes from is just an implementation detail at that point.

When something like this comes up (which is not too frequent), I first see if I am violating Tell, Don't Ask or if I am missing some important UL.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)