BankSimplistic is a sandbox for exploring concepts like Command-Query Responsibility Segregation (CQRS), Event Sourcing and Domain-Driven Design (DDD) with Ruby.
It's unashamedly based on Mark Nijhof's Fohjin from which it borrows the domain model of the sample application (a simple bank) as well as the main elements of its architecture. However, while Fohjin is a Windows app written in C#, BankSimplistic is a Ruby on Rails web app.
BankSimplistic is a Rails 3.0 application so the first thing to do to get started is to install its dependencies:
$ bundle install
For persistence the app uses Redis. So a Redis server is expected to be installed and running on the standard port. This can be done easily in MacOSX like this:
$ brew install redis
$ redis-server
With all that set, the test suite should pass by just running:
$ bundle exec rake
To start the servers in development mode you can use foreman:
$ foreman start
The app is now running at http://localhost:3000
There are some differences in the directory structure comparing to a standard Rails app that are worth noting.
app/models
ActiveRecord is not used, so it's disabled in environment.rb and the models directory is removed.
app/controllers
Traditional ActiveController controllers are used here. The interesting part is the segregation of queries and commands. index and show actions only query the reporting repository, while create, update and delete actions exclusively execute commands.
app/command_handlers
Commands executed from controller actions are handled by the classes in this directory. This additional layer abstracts controllers from the domain model which is never exposed to any presentation layer. The responsibility of a Command Handler is finding the proper Aggregate Root and pass the request along.
The CommandBus module, included in ApplicationController, takes care of looking up the proper handler for the requested command.
app/domain
This is the equivalent to the missing app/models and you'll find the entities and aggregate roots of the domain. As you'd expect, all the domain logic is here. The interesting thing is the use of the Event Sourcing pattern.
AggregateRoot and DomainRepository modules take care of persisting and publishing events as well as restoring domain objects from them. Only events are persisted in the current implementation (no Memento pattern) and we use Redis for that.
app/reporting
Reports are subscribed to events from the domain model and update themselves according to those events. That way they are always in sync but totally uncoupled from the domain model. The reporting repository is denormalized and persisted with Redis.
lib/infrastructure
Infrastructure libraries. Most of the magic is here. Including implementations of the Event Bus using different technologies (ZeroMQ, AMQP, Redis…)
Configuration and initialization can be found at config/initializers/infrastructure.rb (if you want to try alternative Event Buses you should look here)
spec/acceptance
A suite of end-to-end acceptance specs is useful to make sure everything works as expected during the continuous evolution and refactoring of the architecture of the app. A nice pattern that seems to emerge here is that each user story corresponds with a command/event the system is supposed to handle.
We use Capybara to interact with the app but for setting the context, instead of the usual fixtures or factories, we can invoke commands.
No unit specs, everything's way too unstable yet.
This post, along with a series of posts linked from the Fohjin's Readme, elaborates on the architecture and patterns used in the Fohjin sample app, most of which are also implemented in BankSimplistic.
Domain-Driven Design by Eric Evans
For basic concepts like aggregates, aggregate roots, entities, etc. you can find several resources around the web, although the canonical one is the original DDD book by Eric Evans. This is gold.
Udi Dahan is one of the main promoters of the CQRS pattern. This post is a nice introduction to it.
Greg Young is another well known supporter of CQRS, particularly if combined with Event Sourcing. In this post he explains his particular vision of Event Sourcing and the motivations and benefits of using it with CQRS.
Fowler's offers here a more comprehensive description of Event Sourcing, including not only its benefits but also some drawbacks.
If you're interested in exploring further the ideas and patterns behind BankSimplistic feel free to contact me, open issues in the tracker, add comments to the code or fork the project and share your own experiments (there are a lot of things to try by just looking at the original Fohjin).
-- Luismi Cavallé