[UPDATE: This post was written about the time Greg Young formally named his CQS architectural implementation of command query separation.  Because of the change in terminology this post was written with the understanding that CQRS consisted of all elements commonly associated with CQRS.  In other words, CQRS herein is incorrectly defined as the following concepts together: DDD, event sourcing, domain events, true “CQRS”, and eventual consistency.  It should be noted that all of those concepts better fit under the umbrella of “DDDD” or Distributed Domain-Driven Design.  In Greg Young’s recent blog posts he clarifies what CQRS is and is not.]

There are a number of significant advantages to using an emerging pattern known as Command Query Responsibility Segregation (CQRS), formally known as Command Query Separation [Young].

vs. ActiveRecord

ActiveRecord is an incredibly quick and powerful way to create an application to deliver business value as evidenced by the abrupt emergence and fast-growing popularity of Ruby on Rails. Specifically, its power revolves around displaying and mutating objects matching a database schema, thus avoiding such technical complexity as the impedance mismatch problem.

A critical deficiency to ActiveRecord is when business logic reaches a certain level of complexity. Once at that point, ActiveRecord begins to “break down” and it becomes difficult to ensure that all business logic is properly maintained in a single location and handled in a consistent fashion.

Furthermore, all business state is governed by the database. In other words, the database becomes the single point of failure and performance bottleneck. Possible resolutions might include sharding the database but referential integrity and distributed transactions could become an issue. These could be abandoned but that would require more technical complexity to ensure consistent application state. Further, reconstructing a report or screen would then require retrieval of data from disparate sources.

vs. Traditional Domain Model

Domain-Driven Design should be used when business complexity merits the overhead and difficulty of discovering the correct domain model. Otherwise, ActiveRecord or another type of pattern should be used. Even so, DDD has the advantage of isolating all business logic into a single location. Even with "anemic" domain models the logic is still in one place.

A significant downside of traditional DDD is found in the common practice of using an object-relational mapper or similar data access strategy. Specifically, the domain objects may not necessarily be truly “POCO” or “POJO”. For example, in C# you end up having to declare your methods as “virtual” or you may have to create unused, protected constructors. Some ORMs even require you to use a certain base class in order for the ORM to perform its magic.

In addition, many DDDers query their domain objects through a repository for data to display on a report or screen. Many also have their domain objects return a DTO that can be databound to the screen. The problem here is that domain objects are not meant for display—they’re behavioral entities–they have behavior rather than shape. This often results in additional properties on domain model entities to support information needed on a particular report or screen. Lastly, because the domain object is now used for display, there is an extra level of coupling that must be addressed when refactoring domain objects.

CQRS: A Class By Itself

The CQRS style of programming isolates domain complexity into a particular location like its traditional DDD counterpart, but it doesn’t expose state—only behavior through methods that can be invoked and that return "void". In this way, the domain model is strictly behavioral and can more easily be refactored towards deeper insight.

There are a number of significant, positive consequences when using CQRS that you don’t get by default with the aforementioned patterns.

1. Distributed systems capabilities: CQRS facilitates spreading your application across multiple physical machines using messaging patterns.
2. High availability: Because the application is distributed, each piece can continue to function in the absence or failure of any other piece. Further, the distributed nature has a “load leveling” effect whereby spikes in demand are leveled using messaging.
3. External systems integration: Messaging patterns  facilitate the ability to easily replicate both the intent as well as the data of domain events to external systems.
4. NoSQL: CQRS doesn’t even require a database to support the domain model. It only needs a relational database if you choose to use one for reporting. This prevents the reporting database from being a single point of failure or even a bottleneck because it can be scaled independently from the rest of the application.
5. Auditing and historical tracing: I’ve done a lot of work with temporal databases in an attempt to have a complete and accurate audit. (That’s what attracted me to this pattern in the first place.) The problem with temporal DBs and schemas is that the technical complexity quickly overwhelms the business complexity as the two become easily mixed. In CQRS, we capture each state transition explicitly which gives us a complete and accurate historical record that we can fast forward or rewind to any point in time.
6. One repository: There has been some debate over the last few months about the viability of the repository pattern. The argument is that a repository cannot handle all of the querying needs of the application. This is absolutely, 100% correct, which is why we should only use the repository in the domain model to query by ID in order to get a single domain object back. When we need data for a particular screen or report we should use the correct tool for the job and go straight to the database. This is what databases are designed for and CQRS appropriately pushes us in that direction.
7. Screen-based reporting: Rather than trying to bind domain objects to the screen, CQRS tells us to query the database directly and to have simple DTOs which are screen-based objects. This allows us to query all the information necessary for a particular screen in a single request rather than 3, 4, 5, or even 15 DB requests per screen. This also makes development using MVC patterns significantly easier.

Conclusion

While reading technical blog posts or listening to technical podcasts, I am constantly amazed at how elegantly and beautifully CQRS solves a multitude of deficiencies found in more established or “more traditional” approaches.

In a former life, I wouldn’t think twice about using dependency injection to put behavior into a domain object.  But the more I learned about traditional DDD, the more I found that it was considered “taboo” to inject things into your entity objects.  Obviously injecting behavior into domain services was okay, but entities were special.  Of course, this topic is still a matter of debate among DDDers and there are people on both sides of the line.

Last night, while I was reviewing some CQRS principles, I decided to watch the original video recording that introduced me to DDDD.  I’ve seen it a few times, but something stuck out at me regarding DI and entity objects.  Specifically at 15:30 in the video Greg talks about DI: “My rule of thumb when it comes to things like dependency injection is that coupling is okay if it’s at the same layer.”

This does not mean that we are free to inject anything that we want into our entity objects.  For example, it is not okay do inject an EmailGatewayService or something like that into our entity—because EmailGatewayService wouldn’t have anything to do with our domain—it’s a purely infrastructure concern.  Instead we should send a message to the EmailGatewayService.  It does mean that we can inject *domain services* for the domain into an entity object.

ORMs vs. DI

I appears that one of the biggest deterrents to using DI with entity objects is that, in traditional DDD, your entity objects are hydrated using an ORM.   Hooking into the hydration process isn’t very fun and can be a little sticky depending on your ORM of choice.  I’ve worked through this before and, while possible, isn’t a particularly elegant solution and very often feels like a hack.

But in DDDD, on the other hand, dependency injection is quite easy.  Because you’re dealing with true POCO/POJO object and you control the full object lifecycle and rehydration via the event stream, you can easily inject domain services into your entities.

Flip Flop?

Does this represent a shift in my previous thinking?  Absolutely.  But the worst thing that we can do as developers is to blindly cling to a convention.  As part of our growth we should be able to re-evaluate decisions in light of new understanding and be able to make more educated decisions as a result.  In other words, yes, I changed my mind–but only because of a new understanding, a new point of view, a new paradigm.

“And the end of all our wanders will be to arrive where you started and to know the place for the first time.”

I am a big fan of “the simplest thing that could possibly work”.  The elegance and simplicity of the following code is hard to overstate:

public static Func Now = () => DateTime.Now

It’s wonderful because there are no external dependencies, no external libraries, and no versioning issues.  Furthermore, we’ve placed a layer of indirection such that we can easily substitute calls to DateTime.[Utc]Now as necessary.

The only problem with this code is that it works at a single layer.  If you were doing a full-blown integration test (and mocking time for some reason), you would have to ensure that all each individual library that had a dependency upon time had their own individual representation of “public static Func Now” properly set.

One possible solution would be…another layer of indirection.  Specifically, during application wire-up and IoC configuration/setup, you simply re-assign the “Now” instance for each library (probably doing some kind of reflective search/wire-up) with something like the following:

public static Func Now = () => SystemTime.Now

Where “SystemTime” is a thread-local instance of time (if mocked), otherwise DateTime.[Utc]Now is called.  Thread isolation is important because each thread can now have their own representation of time, if desired.

Win-Win?

What does the above scenario give us?

1. By utilizing the standard “Func Now = () => DateTime.Now”, we have absolutely *zero* dependencies on external, non-BCL libraries.  That’s a huge win because we avoid versioning-related issues.
2. By re-assigning the value of “Now” to SystemTime.Now during IoC wire-up/app startup/unit testing [SetUp], we have the ability to mock/fake time all the way down from the top layer/application-tier through to the bottom layer/infrastructure tier with a single statement, e.g. “using (SystemTime.Is(fakeTime)) { … }”

It feels like a win-win because only the host application’s IoC container needs to be aware of this external dependency and we keep our application/library code as simple as possible.

In my previous post, I talked about a technique that I saw for testing time and also about how I simply injected some kind of ISystemTime/IClock interface.  The problem with that was having to do injection at every level—including domain entities.

Oren Eini’s method, while probably the most simple and easiest to implement (both of which are *good things*) has two small issues:

1. Implicit disposability.  You have to remember to reset the static lambda expression every time it’s set.
2. Thread isolation: All calls are to a single, static instance and return the same value—running unit tests in parallel can be dangerous.

With that I mind I decided to create my own small library to address those issues.

Oh No!  Another Library

In the past I would normally have put this new code into a library with other infrastructure code.  I purposefully avoided mixing this code with any other concern because I want to have a truly static library—one that I compile and continue to use for the next five years without updating it.  I want a library that any and all projects can depend upon and has a stable implementation and can be considered as fundamental as Microsoft’s BCL (System.*) implementations.

OpenXtensions

Therefore, I present OpenXtensions.SystemTime.  I named it that facilitate Google-fo.  OpenXtensions.* will be a set of small libraries related to simple, helper methods and behavior surrounding deficiencies and rough spots in the BCL.  Common usage looks like the following:

var instant = DateTime.Parse(‘”2000-01-01”);

using (SystemTime.Is(instant))

{

    // do some work

    var currentTime = SystemTime.UtcNow;

}

The library is about 7K and is signed with a strong key.  It is under the MIT license so you’re free to do whatever you’d like with it.

Dependency Injection

For those of you who want to continue to use dependency injection, I created an interface ISystemTime as well as a class SystemTimeAdapter (which implements ISystemTime).  You can inject this into your objects as necessary and it will call SystemTime.UtcNow on your behalf.

UPDATE: Davy Brion linked to my previous article on this subject.  In the comments for Davy’s post, Mel Grubb linked to his solution, which is very similar to the one I have detailed here.  For what it’s worth, one key different would be that Mel stores a “DateTimeContext” on the thread while I’m storing the DateTime.

[UPDATE: I have created an open source library based upon the concepts found below.]

In my early experience with DDD, I loved injecting dependencies into my domain entities.  I have since repented.  The one downright nasty dependency that we could never quite slip away from was…time.  That’s right, temporal couplings.  Well, not exactly.  Instead, we had to couple to an object that provides the current time.

Initially we had used a “TimeService”, basically just a service that you would inject (ugh) into your entities so that they could query the current time.

We’ve kicked around a few alternatives because we have always wanted to stay away from System.DateTime.UtcNow—mocking that particular class isn’t fun.

Udi Dahan has written about fully encapsulated domain models.  His third take on the subject was very insightful, but I couldn’t bring myself to use the static singleton reference he had for publishing events.  At first glance, this is completely unrelated to what I’m talking about.

Today when I read Mark Needham’s post regarding testability and DateTime, I thought back to the days when we hit issues with that.  But then I saw a comment by Ryan Roberts.  He showed his solution for the problem they had with time:

I use a ..static DomainTime.Instance shim to control datetime in tests.

Ends up with something like

using(DomainTime.Is(new(DateTime(2003,10,10))
{
    var model = SomeRandomModel.JustTheUsualMethod();
    DomainTime.HasBeen(new TimeSpan(0,0,0,1));

    Assert.AreEqual(..)
}

It’s simple and brilliant.  Just use a static singleton instance (like Udi does, but for time) that you can easily mock and do it within the context of a using statement.  In this manner, we can control the value of “now” within our tests or our code.

UPDATE: I’ve read both of these articles previously, but I’m referencing them here because they have interesting and relevant discussion:

• Jimmy Bogard: SystemTime vs ISystemClock
• Oren Eini: Dealing with time in tests
• Dru Sellers: Kick the DateTime.Now addiction
• Phillip Sumi: Time Measurement in Tests

In a few of Greg’s video presentations regarding DDDD, he mentions using a circular, disk-backed buffer.  As far as I can tell, he’s using this as a temporary storage mechanism when events are committed.  He then has a single consumer reading the events from this buffer and putting them into the permanent event store.

I just read an interesting article by one of the .NET CLR guys about building a thread-safe, producer/consumer buffer.  This buffer could potentially be used as the temporary storage before pushing committed events into permanent storage.

One critical difference between Git submodules and Subversion “externals” is the concept that submodules are locked to a particular commit.  Normally this is a “good thing” because blindly attaching yourself to a particular branch in Subversion can have interesting an unexpected consequences when the branch changes out from underneath you.  Subversion provides a way to “lock” to a particular revision via the “-r” parameter in the svn:externals declaration, e.g.”name –r commit_url”.

One of the great benefits and drawbacks about Git is that it doesn’t protect you from the itself.  It’s very much a leaky abstraction.  Because of this, you have the power you can do pretty much anything you want to a Git repository—effectively carte blanche.  One area in which this does not apply is submodules.  Submodules are locked to exactly one revision and that’s the way it is as far as Git is concerned.

There are three ways to update submodules to a new commit.

1. By hand—via git pull within the submodule and then a commit on the supermodule.
2. With a script to be invoked by hand or automatically by a build server which performs the operation of #1 but in a consistent fashion.
3. A post-checkout script automatically invoked by Git.

We have opted for option #2, at least for the time being.

A Better Way

Unfortunately as of this writing, there doesn’t appear to be a better way to solve this issue.  This is why I propose the “—track” option for submodules.

Git branches can be tracked by using the “–track” option when creating a branch.  This same approach would make sense for a submodule as well.  Why not, when creating a submodule have something like this:

git submodule add –track BRANCH_TO_TRACK>

The idea would be that the submodule would “track” the current head of a particular repository branch.  In this way, the default behavior is preserved and those that *want* enough rope to hang themselves if they aren’t careful may do so at their own risk.

The .gitmodules file and .git/config file would be modified to have the following attribute:

[submodule “local/path”]

path = local/path

url = remote_url.git

track = remote_branch_name

In our current build infrastructure, we currently modify the .gitmodules file with the “track” option and have a script check for the track option so that we can follow a particular branch when the script is invoked.