Domain CQRS Blog

At the moment there are many ways to implement Domain Driven Design, Command Query Responsibilty Segregation and Event Sourcing, if you looks at answers on the Google dddcqrs list and some of the samples floating around the answer appears to be to either roll your own and/or don't use event sourcing and/or pollute everything with framework code.

In creating the Domain CQRS framework, there were a number of aims, or principles, that I wanted to adhere to

• Domain models with no dependencies
• Bridge between a domain model, the CQRS pattern and an event store
• .Net 2.0 compatibility
• Extensible
• Fluent configuration
• A "dog food" sample

Domain Models With No Dependencies

The Domain Layer should be at the heart of an application, for this framework that includes the CQRS and Event Sourcing part as well.

Parts that make up this layer include

• Aggregate Roots (and Sagas)
• Commands
• Events
• Projectors (to read models)
• Read Models (and their Repositories)

All of these components should be free from the touch of any framework.

That's not to say that the framework won't provide things (like interfaces and attributes) which can help describe how the parts fit together, just that they aren't necessary.

Bridge Between Domain, CQRS and ES

This framework will deal with these three concepts as a whole architecture/pattern, whilst it may be possible to replace one of them with something else, eg. an RDBMS for ES, that would be working against the framework not with it and would increase the friction of using the framework.

.Net 2.0 Compatability

There are some very cool things you can do in .Net 3.5+, especially around LINQ, expression trees and lamdas.

However I believe that framework developers have some responsibilty to those who can't choose to target the newer frameworks for whatever reason.

Except for continuations, everything can be done in .Net 2.0 anyway with compiled delegates.  Sure it's harder and a little trickier but any competent .Net programmer can build them, and if worst-comes-to-worst you write the code, disassemble it and copy the IL, not good for karma but it works!

Extensible

Each component of the framework should be able to be replaced or customised to suit.  All framework components should be built following SOLID principles.

Fluent Configuration

There are a number of projects which do fluent configuration, eg. NServiceBus, and like any good idea it's worth stealing.

The framework contains a number of components and setting them up should almost read like a sentence.

"Dog Food" Sample

This is a classic Microsoft practice, it definitely improves the quality of the product.  In this case I have chosen this very Blog to dog food the framework.  Not every part of the framework may be needed but I hope to get good enough coverage in this reasonably real world application that it will serve as a good sample for the framework itself.