It's a good question, and to be entirely honest, the case is not 100% solved even at Lokad.
One of the core difficulty to address this question is that Lokad.Cloud and Lokad.CQRS come:
- from different backgrounds:
- Lokad.Cloud orginates from the hard-core data analytics back-end.
- Lokad.CQRS originates from our behavioral apps.
- with different intents:
- Lokad.Cloud wants to simplify hard-core distributed algorithmics.
- Lokad.CQRS wants to provide flexibililty, auditability, extensibility (*).
- and different philosophies:
- Lokad.Cloud is a sticky framework, it defines pretty much how your app is architected.
- Lokad.CQRS is more a NoFramework, precisely designed to minimally impact the app.
(*) without compromising scalability, however scalability is not the primary purpose.
Then, historically, Lokad.Cloud has been developed first (which is a mixed blessing), and, as we have been moving forward, we have started to partition into standalone sub-projects:
- Lokad.Cloud.Storage, the O/C mapper (object to cloud), dedicated to the interactions with the Azure Storage.
- Lokad.Cloud.AppHost, an AppDomain isolation layer to enable dynamic assembly loading within Azure Worker roles (aka reboot a VM with new assemblies in 5s instead of 5min). (**)
- Lokad.Cloud.Provisioning, a toolkit for the Windows Azure Management API.
(**) Lokad.Cloud does not leverage Lokad.Cloud.AppHost yet, it still relyies on a very similar component (which was developed first, and, as such, is not as properly decoupled than AppHost)
Those sub-projects end-up combined into Lokad.Cloud but they can be used independently. Both Lokad.Cloud.AppHost and Lokad.Cloud.Provisioning are fully compatible with Lokad.CQRS.
The case of Lokad.Cloud.Storage is a bit more complicated because Lokad.CQRS because Lokad.CQRS already has its own Azure Storage layer which focuses on CQRS-style storage abstractions. In particular, Lokad.CQRS emphasizes interoperable storage abstractions where the local file storage can be used in place of the cloud storage.
As far I can speak for Lokad.CQRS (see the projet boss), the project will keep evolving focusing on enterprise software practices, aka not so much what the framework delivers, but rather how it's intended to structure the app. Then, Lokad.CQRS might be completed by:
- tools at some point such as a maintenance console.
- refined storage abstractions (probably event-centric ones).
In constrast, Lokad.Cloud will continue its partitioning process to become decoupled and more flexible. In particular,
- the cloud runtime
- the service execution strategy
are still very heavily coupled to other concepts within the execution framework, and likely candidates for sub-projects of their own.
Combining Lokad.Cloud and Lokad.CQRS?
I would not advise to combine Lokad.Cloud (execution framework) with Lokad.CQRS within the same app. At Lokad, we don't have any project that adopts this pattern, and the resulting architcture seems fuzzy.
However, if we consider the sub-projects of Lokad.Cloud, then the combination Lokad.CQRS + Lokad.Cloud.AppHost + Lokad.Cloud.Provisioning does make a lot of sense.
Then, it's possible to adopt a SOA architecture where some heavy-duty functional logic gets isolated, behind an API, into the Lokad.Cloud execution framework, while the bulk of the app adopt CQRS patterns through Lokad.CQRS. This pattern has been adopted to some extent at Lokad.