As you know, I’ve been experimenting with event sourcing for quite some time. My latest experiments are  based on Rinat Abdullin’s post (ideas) and on Greg Young’s Event Store and Ayende’s RavenDB (technology).

The idea is very simple. Because a picture is worth thousand words, take a look at this diagram:

As you can see, a system is broken down into services. Services communicate only via events. Each service contains a user interface and/or API which can be mashed up with other services’ UIs and APIs to in order to implement complex use cases. A service consists of following kinds of components:

  • receptors which react on other services’ events and send commands to command handlers within the service
  • command handlers which process commands. As a result, new events are generated within the service
  • view projections which process events generated within the service populating views
  • resources which return their representations based on data contained in views and/or transform representations sent by a client into commands

What’s interesting about this architecture is, using some experimental code I’ve written I can easily achieve 250 transaction per second on my 2 year old laptop. And by transaction I mean a proper and-to-end transaction, including

  • fetching an event by the receptor,
  • sending a command,
  • fetching the command by the handler,
  • loading an aggregate,
  • calling a business method on the aggregate
  • saving the aggregate (using optimistic concurrency)
  • updating a view

There is quite a lot of space for further optimization. The goal is to be able to run a complex SOA/EDA solution for a big enterprise on a hardware that fits in one rack. Downsizing is the next big thing!

    VN:F [1.9.22_1171]
    Rating: 4.9/5 (7 votes cast)
    Really Simple Architecture, 4.9 out of 5 based on 7 ratings