Jonathan Oliver

There are a number of good resources for getting started on Distributed Domain-Driven Design as well as architectural-level Command Query Separation (not to be confused with CQS as a programming paradigm). Basic Concepts For starters, you should be familiar with "regular" DDD: Domain-Driven Design, DDD Quickly, and Think DDD. Then, you'll probably want to understand about distributed systems because the way that you think about programming in a distributed environment is most definitely not the traditional "request/response" paradigm: Enterprise Integration Patterns, Pattern-Oriented Software Architecture, Volume 4 (Distributed Computing), and Distributed, Event-Based Systems. »

Greg's devTeach talk has various slides in which he presents a simple overview of persistence for event storage. In the video [at 39:30] he talks about how he doesn't use a relational database for storing his events, but he says that you could. Because I have only superficially glanced at solutions like BigTable, HyperTable, and CouchDB, I'm still using a relational database on the back end. Here is a proposed schema for storing the state transitions for any and all events of a bounded context in a SQL Server relational database: »

In virtually all of the video recordings Greg Young's presentations and PowerPoint slides, he talks about an event pipeline that comes out of the repository when events are committed. One small optimization that helps with performance as well as availability of the system is to put the action of writing to your persistence engine as a subscriber on the pipeline rather than attempting to write to the persistence engine when committing the transaction. »

One part of Event Sourcing that could become problematic is those objects with long, complex lifetimes. In virtually all cases, an object's lifetime is relatively short--perhaps a dozen events or so. But there are cases in which an object may live for a very, very long time and be used frequently. Greg gives an example in one if his talks of an object that gets thousands of new events per day. »

In Greg's devTeach presentation he brings up the concept of a write-ahead log, which is a powerful, yet simple mechanism for temporary event storage which is also a capability offered by virtually all relational databases. In a database scenario, the concept is simple: whenever a command is performed, it is performed in memory and immediately recorded in the log. Then, if the database process accidentally restarts/shuts down, etc. it can be brought back to a known state. »

For the past few weeks I have been scouring the Internet investigating all things related to DDDD as well as the concepts behind Command Query Separation at an architectural level. One of the main posts that is referenced is Martin Fowler's work on Event Sourcing. In a nutshell, the article talks about capturing each change to the application state as an object and then persisting those objects. Then, to rebuild the state of an application at a given time, you simply re-run those captured objects against your entity. »

Greg Young talks about using an identity map to help avoid hitting the persistence engine and making it the bottleneck for the entire system. In a fully distributed scenario, the event pipeline coming out of the repository would publish any events committed to an aggregate to all interested parties. These interested parties would include a persistence engine subscriber, other bounded contexts, and other instances of the same bounded context. Other instances of the same bounded context would use an identity map and listen to messages for aggregates that already held in memory--other messages would be ignored. »

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. »

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. »

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. »