A week with Greg Young

We have had the priviledge last week to spend some time with the Greg Young. We had four mind blasting days which consisted of him blowing our minds all over the floor with his concepts and ideas :).

For the first two days he covered his Command Query Resposibility Segregation (CQRS) architecture. For those of you that are familiar with the Command Query seperation pattern, he applies this on an architectural level. In summary he believes that your "write" domain and your "read: domain will always remain in conflict because they will always have different requirements. He believes that you should keep those two domain seperate.

The "write" domain contains all your entities and values objects with all your business rules. This domain provides your business value for your company. The domain expects various input commands and will generate one or many events from those commands. These events will then be routed to an Event Store (which sole responsibility is to store the events) and any other domain interested in those events. This can of course be done synchronously or asynchronously. The async part of course involves more obstacles to overcome but has many benefits as well.

The "read" domain consists of all your DTOs and fullfills your reporting needs in your domain. This domain will typically read from an OLAP store, covert in to DTOs and send it to the UI.

Greg also explained various architectures we can use and how to address many of the architectural pitfalls that you might come accross. He also discusses other interesting topics like Charding and load balancing techniques.

For more information on CQRS, you can view this blog which has a very nice article and source code you can follow.

The second part of the week, Greg gave us a lot of consulting advice surrounding the trading domain. Luckily for us he comes from that domain and has written a very highly scalable system for statistical analysis. He went through his architecture and domain model and also a lot of the pitfalls they encountered while developing the system. Hopefully this will help us avoid similar pitfalls in the near future.