Introduction

Over at a private LinkedIn newsgroup for ENTP personality types, somebody posted a link to "The Seven Habits of Spectacularly unsuccessful Executives". This is a great article, but not a lot of help IMO, instead of telling what not to do, one might be reversing the reasoning, and try to figure out what to do.

I posted this blurb in a comment on the newsgroup, and I figured I might as well post it on the blog as well...

Here we go:

The Seven Habits of Possibly Spectacularly Successful Executives

More...

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...

We zitten in de problemen in ons landje; hoe zou U als ondernemer het probleem aanpakken ? #BeterBelgie

Het geld is op, de mensen komen op straat, er is schrik voor de economische malaise en verdere implicaties er van, ...

Als ondernemer zit U dagelijks in gelijkaardige situaties: uw acties hebben niet alleen impact op producten en bedrijven, maar ook op mensen in een directe of indirecte manier. Bijgevolg heeft het merendeel van U een soort van zesde zintuig ontwikkeld om dergelijke problemen op te lossen.

Daarom wil ik aan U als ondernemers vragen: welke suggestie heeft u voor de overheid ? Hoe kunnen we de problemen in dit land op een pragmatische en efficiënte manier gaan oplossen? Ik vraag dus geen gepalaver vanuit de ivoren toren, maar concrete en uitvoerbare oplossingen die het verschil maken.

More...

Introduction

It was hard keeping this a secret, but I finally can tell you now: I managed to build my very first relatively successful web app.

I built it using NancyFX, Simple.Data and Scritchy in about a month, and it generated 16K Euro during the first month it was in service. After all these non-profit and some other fruitless attempts these microframeworks helped me to push out an idea that has been lingering around in my head for a few months now.

In this post I will explain to you how I evolved a simple idea into a few K of cash within a timeframe of just 2 months...

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...