This is the second and last part of my notes I scribbled down attending the IDDD Tour.

Two weeks ago I got to spend four days attending the IDDD Tour by Vaughn Vernon. Although my book queue has only allowed me to shallowly browse the book, I had high hopes for this course. I anticipated a week of getting lectured on DDD with a few practical exercises, but was blown away by the openne...

Custom enum-like class with extendable properties implementation. It may seems basic but I found it really handy in couple situations where I needed to have more detailed and categorized enums.

A roslyn plugin that looks for duplicated lambda expressions; Once detected, breaks them out into a separate function; Names the function something based on what the function is doing

I've been writing quite a bit about CQS (or command and query separation) lately. In my last post on using events, I already hinted towards bringing in the R; command and query responsibility separation. With CQS, commands can mutate data, while queries can only read that data. CQRS takes this on...

A blog post that explains how to detect when code quality decreases, thanks to the tool NDepend ability to query code through LINQ queries.

Developers are creative people; we love to build stuff. We all spend our days, and sometimes out nights too, building stuff. Building stuff is what we do best, often we just can’t help ourselves. And therein lies the problem....

In the last few posts I settled on an architecture for handling commands and queries. A byproduct of the described approach, is that your codebase quickly racks up plentiful little classes; a class to hold data, and a handler to act on that data, for each use case. There are a few ways you can go...

DRYing up your code could get you into a ton of mess when you don't take the Single responsibility principle into consideration. This article goes into how separating concerns and identifying behaviors could lead to a more flexible code-base

In my first post on this topic, I started out with an attempt to limit abstractions to solely commands and queries. Commands and queries were self-contained and could be invoked by passing them to a context-providing generic handler. The drawback of this approach was that it made constructor depende...

In "Big Ball of Mud", Brian Foote and Joseph Yoder propose that the default (and most common) software architecture in use is the "Big Ball of Mud" pattern and go on to discuss six additional patterns and activities that it gives rise to: "Throwaway Code", "Pieceme...

Inversion of control can be described as the reversal of control in parts of a program. Another way of looking at it is a way of removing dependencies from the code you write. A good way to see what this means and how it works is to look at how we write code

An infrastructure for a variation to the CQS pattern.

This post provides a list of things that you can do to work towards becoming a software architect.