In a previous post, I talked about a possible relational database schema for event storage. I also discussed the idea behind aggregate versioning in a relational store. In this post, I'd like to talk about storage in a non-relational persistence medium, such as CouchDB, HyperTable, or even the file system.
One of the reasons behind the "last_snapshot_seq" column in the relational schema is that is helps determine the point at which to start loading events from the database. »
I just finished watching David Laribee's devTeach video. Towards the middle of the presentation he started talking about domain services and how we can use double dispatching to provide a service to a domain entity. By doing this, we gain the ability for the domain object to call the domain service—without injecting it during construction. This, in turn, facilitates variability because we can provide different implementations of the service which may or may not access other external services or state—all without leaking infrastructure concepts into the domain. »
Greg has generously shed some light on a critical aspect of DDDD: How do I get the command (or event) message into the aggregate root?
First a small amount of background. When a message arrives for consumption, typically a message handler like MapMessageToAggregateRootHandler will be responsible for loading the aggregate from the repository and pushing the message into the aggregate root. (Note: The messages handled by this handler all have a GUID property representing the aggregate ID which the handler can use to load the aggregate from the repository. »
[UPDATE: This article may be better titled as Pipes (Publishers) and Filters (Consumers) because as of a recent message group thread, the concept of "Produce" has been renamed to "Publish".]
As I really started looking at the interface for IConsume and IPublish (sorry, I can't shake putting "I" on interfaces), I was slightly perplexed. In essence, it appears that these two methods could do the same thing: Consume(Message) and Publish(Message) because the method signature is identical except the name. »
About a year ago, Greg wrote a good article on producers and consumers. It's an excellent read but is a little too abstract if you're brand new to DDDD. I would strongly recommend reading (at least three times) each of the previous blog posts from Greg in the DDDD series and watching all of the videos as listed in my Getting Started post.
Fortunately, Greg is very active in the Domain-Driven Design Yahoo Group. »
[UPDATE: Well this is embarrassing. This post is starting to get good amount of traffic and is getting listed on daily link blogs such as Dew Drop. Unlike the other posts in my DDDD series, this particular post was supposed to serve more as a reminder to me, rather than a polished set of coherent and sequential thoughts. It probably got ranked fairly high because it's so keyword dense.]
I have watched the InfoQ video of Eric Evans interviewing Greg Young several times. »
Wouldn't it be great to ensure that you had consistent line lengths in your code files in Visual Studio? All versions of Visual Studio since 2003 have the ability to have what's called a "guide line" as shown below:
You can even have multiple "guide lines".
The following command will add two guidelines, one at column 82 and the other at column 98 (zero-based):
REG ADD "HKCUSoftwareMicrosoftVisualStudio9.0Text Editor" /v Guides /d "RGB(128,0,0) 83, 99 »
There are little nuggets of gold in comments that Greg makes on various groups, such as Yahoo's DDD group. One of them is in regards to the event pipeline.
The responsibility of the event pipeline is "to provide an indexed view of the event storage." In other words, it's like the repository pattern, but this time at a much lower level. Basically we want to make it look like all of the events are in memory. »
Introduction
One of the tough things about DDDD right now is there isn't a mountain of information available like with other programming topics. I guess that's a blessing in disguise because there's also not a ton of misinformation either.
In traditional N-tier systems and in repository-based, DDD systems, we typically let the database manage all of our state for us. Then we use different patterns, such as the optimistic offline lock (AKA optimistic concurrency), to ensure concurrency when multiple processes are trying to modify the same information at roughly the same time. »
In my previous blog post, I elaborated upon Greg's devTeach talk in which he hints at distributing a bounded context. I talked about how using what Greg calls a "locator" can facilitate distribution without introducing concurrency problems.
The question was asked in his talk at 46:40, "Is the locator a single point of failure?" Because his talk was not actually about distributed systems, but rather about CQS and some foundational aspects of DDDD, Greg pulled back from that question and moved on. »