The more I think about having a completely separate reporting context, the more I love the concept.

I love the idea that you can have a read-optimized version of your data.  Obviously this idea is not new, it’s the foundation of data warehousing.  I’m not going down that road quite that far for my situation.  It’s the idea of having reporting be its own bounded context–its own separate sub-domain which is appealing.  Your write-only, sub-domain bounded context would simply make the changes/updates available to the read-only domain in some fashion.

The performance implications of a read-optimized version are staggering.  First of all, you can have a query (as in command/query separation) that retrieves all necessary data in one fell swoop–one database command–for a specific screen, rather than lots of little ones.  Since you have to retrieve all of the necessary data for a particular view, you might as well get it all at the same time.

In 2002, I was kicking around something very similar to this; I would attempt to get all data for a particular screen as part of a single database query (set of queries in a single command).  Performance rocked, but the code was a mess because I was going about it completely wrong.  This was all pre-DDD and the code had a bunch of really nasty side-effects, e.g. welding my business and presentation layers together, etc.  By having a different bounded context, the separation is maintained.

Other performance improvements could obviously be an optimized database table/view structure as well as different indexing strategies, along with the application’s caching strategy.  Finally, the database could be completely replicated–I would probably use something like MySQL Cluster rather than SQL Server Replication in this type of scenario.

Since publishing my last post a few minutes ago, I came across a Develicious post by Casey Charlton.  He’s covered what I have said in significantly more detail.

The really cool thing that he brings out, as we both refer back to some of Greg Young’s architecture concepts, is that the domain/command operations could be in separate bounded context from the reporting bounded context.  In fact, these two systems could have a completely different data store–something that Greg mentioned in his InfoQ video.

As an aside, the thought occurred to me that perhaps you could have the same data store for reading in both models, but writes to that data store were done through a completely different mechanism–use of a message queue.  This way contention of the store could be lowered significantly.  No idea on the consequences of such an move just yet, but it’s something to be analyzed further.

It makes sense to have different bounded contexts and corresponding repositories for domain operations versus reporting because the needs are so different.  Further, you could potentially do all domain, write-based operations in memory and, with the messaging pattern I pointed out above, you could be assured that the commands being performed would have their state persisted, but in a more scalable, asynchronous manner–without making the domain wait until the database connection was opened, written, committed, and closed.

Over the past few months I have been trying to wrap my head around the concept of user input validation and operational validation and how to best handle it.  In many regards, it’s a domain concept so it should be in the domain.  But at the same time, it felt weird to put the validation logic inside of an entity object in a highly reactive, IsValid fashion.  This smacks of doing CRUD operations on a DDD object.

As I have grappled with this problem I have noticed a few more posts on the issue.   Rinat Abdullin has an intriguing post on the matter.  In the end, he raises some valid points–and I like the visual/GUI aspect of what he’s doing.

The catalyst that started driving the concept home for me was Jimmy Bogard’s post on Validation in a DDD world.  He confirmed to me that we don’t want validation in the entities–which I already knew, but couldn’t quite put my finger on.  He then went on to discuss that we want to encapsulate the validation into our command objects and that we should be thinking operationally and in terms of command/query separation.  He then referenced the Blue Bible–Evan’s DDD book.

After re-reading a few sections in my copy of Evan’s book, I wasn’t able to find as much on command/query separation as I had wanted–perhaps because I wasn’t looking in the correct spot.  [UPDATE: It's Chapter 10, Side-Effect Free Functions]  I did a quick Google search for "domain driven design command query separation" and found an excellent–and very recent–InfoQ video clip of CodeBetter’s Greg Young.  This is where things started to get exciting as they began to gel.

Greg talked about how he had a "write-only" domain model with command objects that would represent real world commands.  [In the stereotypical case, things like ChangePassword, PlaceOrder, etc.]  The idea was that the domain objects didn’t really have getters and setters–they simply had commands performed on them in a very Tell Don’t Ask manner.

Then, to populate a screen or web page with pertinent reporting or display information, a completely different, query-object, DTO-based subsystem was used.  These query objects went straight to the data store–through an appropriate layer of encapsulation–to get all the necessary data to populate the screen.  This subsystem handled all reporting needs as well as infrastructure concerns like paging of results.

Greg went into some detail regarding how his system was structured using event sourcing, which seemed to be an incredibly powerful way to create a system–especially the ability to snapshot, replay and rewind a set of changes to a point in time.

All in all, it was a fascinating journey of discovery.  I’ve known about a few of the concepts implicitly–as sort of a gut feeling–but having them made explicit helps bring about a significantly increased level of understanding.

To conclude on validation–how is it done?  Per my understanding at this point, the command object is responsible to perform the validation.  Okay, easy enough.  How is that validation made available to the user in the GUI?  That’s the part that I’m not 100% clear on.  There appears to be several options.  The first is that we return a simple DTO from the command object reporting on the success or failure of the operation with a set of validation errors included.  The second option seems to be to fire some kind of event which includes a set of errors or to have a unique event per error.

I’ll post more as I dig a little deeper.

UPDATE: This is a really good post from Derek Bailey, more especially the comments from Scott Bellware.

I’m baffled by the podcast from Jeff and Joel.  In many regards, I have had the same reaction as Robert Martin.  In our organization we have tried our best to implement SOLID principles.  The affect that these principles have had on our ability to produce software is both profound and staggering.

To basically say that things like the Single Responsibility Principle and the Dependency Inversion Principle are "bureaucratic" and that they come from someone who "doesn’t write a lot of code" is absurd.  It reminds me of a self-convinced teenager who cannot be taught because he knows everything already.

It is said that humility is the mother of all virtues–courage is the father.  Humility in developing software facilitates our growth.  Only when I admitted to myself that there were recurring problems in some of my designs did I become open to accepting other points of view–especially Robert Martin.

Granted, Joel’s online personality seems to be abrasive on purpose, which causes people to take notice of him.  Perhaps this most recent backlash from the blogosphere is the best thing that has happened to him in a while because it drums up attention and thus business for his software.  Personally, it’s not the type of attention I would want for my company.

I am thankful for people like Robert Martin, Kent Beck, Martin Fowler, Eric Evans, among others who share their learning with the community such that we can all grow thereby and move forward in significant ways as an industry.  Too many think software development is a job–a paycheck.  It’s the mentors that help us view it in a correct light–as a craft–one to be mastered.  "And the end of all our wanderings will be to arrive where we started and know the place for the first time."