x86 vs x64

When running the example on a x86 machine you have to go into the /Lib/sqlite/bin/ folder 
and copy the three System.Data.SQLite.* files into the /Lib/sqlite/bin/x64/ folder. This 
is because I am developing on a x64 system. An interesting fact is that the TestDriven.Net
test runner does actually run in x86 mode, so the SQLite reference in the Test project is 
the the x86 SQLite version already. Resharper test runner acts the same.

If you have any questions or other feedback then I would love to hear about it at
[email protected]

I have also written a few blog posts about this CQRS example application:

CQRS a la Greg Young
Link: http://cre8ivethought.com/blog/2009/11/12/cqrs--la-greg-young/
Intro: I have had the pleasure of spending a 2 day course and many
geek beers with Greg Young talking about Domain-Driven Design
specifically focussed on the Command and Query Responsibility
Segregation (CQRS) pattern. Greg has taken Domain-Driven Design from
how Eric Evans describes it in his book and has adapted mostly the
technical implementation of it.

CQRS Domain Events
Link: http://cre8ivethought.com/blog/2009/11/20/cqrs-domain-events/
Intro: As you may have seen in my previous post “CQRS à la Greg Young”
now our domain aggregate root is responsible for publishing domain
events indicating that some internal state has changed. In fact state
changes within our aggregate root are only allowed through such domain
events.

CQRS Domain State
Link: http://cre8ivethought.com/blog/2009/12/08/cqrs-domain-state/
Intro: This morning Aaron Jensen asked a really interesting question
on Twitter “Should Aggregate Roots en Entities always keep their state
if it is not needed for business decisions? Is firing events and
relying on the reporting store enough?”.

Specifications <-- explaining the base test fixture class
Link: http://cre8ivethought.com/blog/2009/12/22/specifications/
Intro: I received a couple questions about the Specification Framework
that I use in the CQRS example and thought lets talk about that for a
bit. The first thing that should be underlined is that this is not a
framework, they are a few classes and extension methods that rely on
NUnit for the actual assertions and and Moq  for mocking of the
dependencies. I got the initial bits from Greg Young at his DDD course
which I extended a little bit for my specific needs.

CQRS Event Sourcing
Link: http://cre8ivethought.com/blog/2010/02/05/cqrs-event-sourcing/
Intro: So after reading this blog post by Rob Conery about Reporting
In NoSQL where he explains very well what the problem is when using a
RDBMS for persisting the state of your domain, or really anything that
is written with Object Orientation in mind.

CQRS Event Versioning
Link: http://cre8ivethought.com/blog/2010/02/09/cqrs-event-versioning/
Intro: When using Event Sourcing you store your events in an Event
Store. This Event Store can only insert new events and read historical
events, nothing more nothing less. So when you change your domain
logic and also the events belonging to this behavior, then you cannot
go back into the Event Store and do a one time convert of all the
historical events belonging to the same behavior. The Event Store
needs to stay intact, that is one of its powers.

CQRS Scaling
Link: http://cre8ivethought.com/blog/2010/02/09/cqrs-scalability/
Intro: Scalability is one of the several different benefits you gain
from applying CQRS and Event Sourcing to your application
architecture. And that is what I wanted to take a closer look at in
this post.

Using conventions with Passive View
Link: http://cre8ivethought.com/blog/2009/12/19/using-conventions-with-passive-view/
Intro: I was reading Ayende’s blog post about building UI based on
conventions and thought; hey I have something similar in my CQRS
example. And since this is the least interesting part of the whole
example I guess it will be missed by many, and I can’t let that
happen.

-Mark