Planning the Windows 8 Cookbook

I'm currently at Microsoft's Build conference and we're all receiving a Surface RT tablet. That means it's a great moment to talk about my plans for the Windows 8 Cookbook. I know, I know, it's a cheesy name so just be aware that I'm open to better suggestions. Since Silverlight is mostly dead, I've decided to revive the Silverlight Cookbook by rebuilding it as a Windows Store app instead. This time I'm also going to get some help on the UI design so hopefully it will finally get a decent looking front-end.

Another thing I'm considering is to host the entire project on GitHub. I've already build up some experience with Git on CodePlex as the result of a recent conversion of my Fluent Assertions project, but I'd like to get to know how that compares to the GitHub experience. Whether or not it's going to be CodePlex or GitHub, I will be accepting pull requests. And if you are interested in contributing a bit more directly, I'm also looking forward to people who want to help me build the project.

To give you some more context on the technical platform behind the cookbook, here are some of the things I'd like to use:

• Caliburn.Micro for WinRT
• Autofac for Portable Libraries
• A domain model designed according to Effective Aggregate Design
• Command Query Separation using Cutting Edge's Query and Command implementations
• MSpec combined with Fluent Assertions and FakeItEasy
• WCF to connect the Windows 8 C#/XAML client with the .NET 4.0 application server
• The Fluent Migrator framework for maintaining a database scheme from code (if I'll go for a relational database)

The Cookbook is supposed to demonstrate how to build line-of-business applications based on the Windows Store platform. That means it's going to use some design decisions that are completely overkill for this particular example, but should be very relevant for real-life projects.

One thing on which I'm still in doubt of is the data access strategy. I'm well aware that Event Sourcing shouldn't be used without careful considering. But the fact of the matter is that I'm doing a project right now where we wanted to use RavenDB, but decided to go for Event Sourcing using a traditional database instead. These are the four choices I have in mind.

Aggregate storage with…

1. SQL Server using NHibernate
2. RavenDB for storing the aggregates and using its Lucene-based indexing engine for querying

…or Event Sourcing using Jonathan Oliver's EventStore combined with Lokad.CQRS's aggregate design

1. Using SQL Server as its backing store as well as a query store.
2. Using RavenDB for storing both the events and the query models, optionally adding faceted search options provided by Lucene.

I have to admit, this seems to be quite an ambitious project to be doing during free evenings. But I'll be reusing a lot of code from the Silverlight Cookbook, so that should save some time.

Let me know what you think of the direction I plan go in. You can email me, tweet me, or spend a few minutes of your valuable to fill in this survey.