Monday 16 November 2009

Version 0.4

This release was meant to clean-up the CI stuff. Finally I managed to get scenario-based integration test 'From Hongkong to Stockholm' working correctly using SQLite both on TeamCity and localy.

There is also some increment with regard to functionality. I added 'Next expected activity' feature and modified main menu slightly. It now includes a page for listing all registered cargoes (helps greatly in testing).

Please, download from here and try if you like it!

Tuesday 10 November 2009

Continous Integration

Hi all!

I am proud to announce that DDDSample.Net finally has a Continous Integration configured. Big thanks to Kyle who accepted my registration request for a place on CodeBetter TeamCity server.

Direct effect of this event is the 'Most recent builds' area where you can track project progress. The indirect effect is that development work will be streamlined and finally there will be some hammer to hit me when I break the build.

Next thing to do is to create a WiX script to replace the Setup Project (setup projects require Visual Studio to be installed on the machine in order to generate the installation package).

In the meantime I will try to release the 0.4 version of DDDSample. Stay tuned!

Tuesday 3 November 2009

Command Query Separation

Command Query Separation is an architectural style which encourages building two separate models for one particular domain. One model is optimized for commands (modifications, like inserts, updates and deletes) and the other is optimized for queries (probably using star, warehouse-like schema).

The goals of CQS are to make both subsystems scale well using methods best suited for each one and to free the command model (which encapsulates the core business logic) from UI related code.

DDDSample is an implementation of sample from Eric Evans' book and, as such, is not using CQS principles. It is that because its purpose is to demonstrate basics of DDD not 'polluted' by derived concepts.

Yet the DDD 'knowledge crunching' process demonstrated in the book by Evans leads to a model which is very well suited for scaling. How is it done?

It is simply because DDDSample (as well as my .NET version) is built according to other good DDD practice--one which says that communication between aggregates is asynchronous. Despite not being named officially as CSQ-driven, DDDSample model has two aggregates representing the same concept (Cargo), one optimized for commands and the other one for queries.

Most of processing-intensive operations of Cargo entity are being done via Handling aggregate which asynchronously pushes notifications into the Cargo aggregate. The latter contains a lot of redundant information which is optimized for searching cargoes and displaying cargo information on the screen.

When I was thinking about future of DDDSample.Net I thought about CQS in the first place. After careful analysis I know it will not give any breaktrough in the field of scalability, but I hope it will make these scalability enabling aspects more explicit in the codebase and will clean up the core business code from presentation concerns.