Introduction

In one of my numerous attempts to create a neat approach to CQRS, this is yet another attempt to remove all the protocol that CQRS requires. I love bootstrapping new projects and experimenting with new approaches, and this is another step that improves efficiency. It is a natural evolution to one of my other CQRS playgrounds: Scritchy.

The conventional CQRS approach requires you to write command - and event classes, to wire up your commands and event handlers to the relevant AR's, saga's and viewmodel builders.
I removed some of the clutter in that process with Scritchy. Scritchy uses conventions to wire up the commands and events to the relevant components. This makes CQRS a lot less verbose while still offers the same advantages.

Scritchy v2 ?

While this is a good attempt, it still requires you to write the dreaded event - and command classes. Having pushed some best practices/usages/libs to some enterprise teams in the past, I noticed the following: any change that adds extra steps/work to the process makes acceptance harder by devs, as most people are usually trapped in a certain approach, and they do not see an advantage in having to write more code to do the same thing. If they do not need to write all the "protocol"/extra classes, you have removed yet another step that might slow down acceptance of the practice.

The new approach I am about to tell you about in this blog post completely hides the messages from the dev, i.e. the dev can just use a conventional method call, and messages are created underneath.

Disclaimer

This is a possible approach to the problem, but I tend to think that the majority of the CQRS evangelists and practitioners value explicitness over pragmatism. I love the explicitness and clarity of their examples and implementations, but in the real world most people start to think: "Wow, that is a lot of code to simply add an item to the stock; are they nuts ?".

Having experienced the fallacy of the explicitness in a startup attempt, my brain got tickled to find fast and neat approaches to a pretty established conventional path. I think this one is pretty close.

The full source is available over at GitHub, and the demo app can be seen/tested over at appharbor.

Example

So without further ado, here I will show you ALL THE CODE required to implement a complete CQRS app:

More...

One of my main motivators, my youngest son Matisse #PrideAndJoy

Introduction

I like the concept of retrospectives; it makes you self-reflect and think about the paths you followed and want to follow in the future. As it has been 2 years ago since my latest retrospective, I think doing a post on it right now might be a good idea.

More...

Introduction

I am currently in the process of studying F# - a functional programming language -. Since I am a big fan of meta-cognition, I am trying to find out how the mindset of the functional programming paradigm differs from that of a C# one (i.e. the more conventional, object oriented paradigm).

This essay also tries to point out some existing bridges to the functional paradigm that are currently implemented in the imperative programming language C#.

What is "Functional programming" exactly ?

I will reference wikipedia - while it still exists - for the definitions:

In computer science, functional programming is a programming paradigm 
that treats computation as the evaluation of mathematical functions 
and avoids state and mutable data. 
It emphasizes the application of functions, in contrast to the imperative 
programming style, which emphasizes changes in state.

Let us start with the first bit:

More...

Introduction

The concept behind CQRS is neat: detach your domain implementation completely from your representation requirements. I even wrote a framework for it as a learning tool, so somebody without any prior experience should be able to boot a CQRS app in a few minutes.

The main idea behind this framework is providing developers new to CQRS an operating room where they can compose their own little CQRS Frankenstein app.

The whole framework is constructed in a way that it forces you to make your domain implementation completely persistence ignorant, respecting typical AR/transactional boundaries.

Scritchy is not "the framework to write CQRS apps"; Scritchy is a framework that tries to provide you a learning platform where you can start grasping the basic principles, advantages and disadvantages in using CQRS.

Once you understand the basic principles behind the CQRS setup, and why everything is setup the way it is, I would advise anybody to gradually replace parts of the framework and just opt for whatever approach you like, using proper message busses, pub/sub/... 

If you write your app following the conventions Scritchy dictates, the only thing you need to change to remove the Scritchy dependency is the base object your Aggregate Root inherits from; that is the only dependency that is ever necessary in you app implementation. This was by design,to make future migrations as easy as possible.

I wrote this framework to enable a dev new to CQRS to get his app up and running in a few minutes... But apparently that is not enough....

More...

Introduction.

Everybody loves experts, at least I know I do! I love being able to toss almost every single question or problem to one or more experts in order to gain new insights and understandings.

In most cases, your knowledge network really grows exponentially as you age. Knowledge networks should be cherished and nurtured, as they will allow you to accelerate your personal knowledge growth in an exponential rate.

But, there is a catch: can you remember the last time you disagreed with an expert ?

There is an common acronym on the internet: "KIP", which is short for "Knowledge is power" - it is also the Dutch word for "chicken", but that is completely irrelevant in this essay - . In most cases, I tend to agree, but in some I do not... Here is an explanation:

More...

Introduction

Most people who get started with CQRS have issues with this classical example: "how do we verify username uniqueness when a new user registers ?".

While user authentication is something that has been implemented numerous amounts of times before, and one should usually not reinvent the wheel but use an existing software library for this particular case, the problem in itself is rather interesting, and happens quite a lot in a domain.

In this small article I will show you a simple proper way to resolve the issue respecting CQRS/DDD principles.

More...

Introduction

This article will show you how you can do TDD/BDD with Visual Studio Express editions. While most people say it is not possible, it is actually pretty easy.

Prerequisites

• A Visual Studio Express edition
• AutoTest.Net
• Nuget

How do you do it ?

More...

Introduction

CQRS is one of my architectural pet peeves, as you might have noticed from the numerous amount of blog posts I made on this subject. However, I noticed the concept is complicated and hard to grasp for newcomers to CQRS. I have been spiking numerous attempts of a framework that makes CQRS both more manageable and understandable, failed hundreds of times, and even published a few of my acceptable attempts as gists over at github...

A few days ago I was messing around with SignalR trying to setup again another CQRS attempt, and failed miserably.... However, 2 nights after that approach I had an ephiphany which had been lingering around in my head ever since.

Today I decided to get back to business, so this afternoon I started spiking a proof of concept (POC).

I think you will be happy to see that I managed to get most of the annoyance out of CQRS with this simple concept.

More...

Introduction

I just finished commenting someone's opinion on the MBTI personality type in a linkedin status update.

As you might have read in my previous post regarding "The secret sauce of great leadership - IMO ;)" I am an avid fan of determining your own personality type in order to improve yourself.

Because this person had seen a presentation by Patrick Vermeren on the myth of MBTI, he retweeted the following:

I wish there was a test to take to find out how much you hate Meyers-Briggs (MBTI). I'd score off the charts.

Since I most certainly do not agree, I commented some things on the linkedin thread. As I think the comment might have some value for my blog readers as well, I decided to post it here as well:

More...

Introduction

What MBTI personality type are are you ? If you do not know, I would suggest you find it out (I did it here, it only takes a few minutes).

I did it, and it was an epiphany. Apparently, I am an ENTP. For years, I felt like I did not know anybody who had a personality similar to mine. Now I do, and I found some great online discussion groups all populated with aligned personalities.

In one of those threads, we had a great discussion on how your personality influences your professional life.

Enough off-topic blahblahblah™, time to get to the subject. In the mentioned discussion thread, I gave away my "secret sauce of great leadership - IMO ;) -", just like that, for free... As I received some great comments, I was thinking: "Maybe posting this to my blog might be helpfull for some readers as well". So I did.

Unlike most of the stuff the Oracles out there are spreading, it is not some kind of a magic formula, on the contrary: it is hard work. It is also small and coincise; there is no need to overcomplicate things.. This is my personal approach. I use it all the time, and it works for me. 

So without further ado, here we go; this is my personal ...

"Secret sauce of great leadership - IMO ;) -"

More...