Reflective Software

Eventual Consistency via Domain Events and Azure Service Bus

Published on 1st September 20151st September 2015 by Florin

I’m going to start this article by explaining what Eventual Consistency is, how it compares to Transactional Consistency, and when we should consider designing a solution with this approach. Next we’re going to look at Domain Events, see what their role is in relation to eventual consistency and also how we can identify them in the domain language. Finally, based on a simple scenario, we’ll go through the implementation details of a proposed architecture, using Azure Service Bus messaging system.

Transactional vs Eventual

As the name implies it, eventual consistency is about being consistent, well, eventually. In this context eventually means at a later time. It’s easier to understand this concept when comparing it to transactional consistency, as in the following diagrams:

A SOL[I]D refactoring exercise – Part 5

Published on 14th August 2015 by Florin

This is the last article of the SOLID series. In the previous article we’ve seen how to identify and fix a violation of the Liskov Substitution Principle.

A SO[L]ID refactoring exercise – Part 4

Published on 13th August 2015 by Florin

The solutions has once again been refactored, this time by applying the Open Closed Principle. Now the latest version of StudentService class looks like this:

A S[O]LID refactoring exercise – Part 3

Published on 12th August 201512th August 2015 by Florin

In the previous article we covered the Single Responsibility Principle and continued refactoring the solution accordingly. As a result, now the Student class looks like this:

A [S]OLID refactoring exercise – Part 2

Published on 11th August 201511th August 2015 by Florin

In the first part of the SOLID series we’ve looked at the Dependency Inversion Principle. After the initial refactoring attempt now the StudentService class looks like this:

A SOLI[D] refactoring exercise – Part 1

Published on 10th August 201510th August 2015 by Florin

I initially planned to write about the SOLID principles in isolation, taking them one by one, defining them, and then coming up with a simple fit for purpose scenario complemented by some nice diagrams. But I soon I realised that almost all my knowledge on the subject, either coming from books or the internet, is based on the same type of articles.

Therefore, in an attempt to make things a bit more interesting, my approach is to have a single piece of code based on a scenario (as close as possible to real life) and work through refactoring this code using the SOLID principles. By doing this I’m hoping that this article will provide a bit more insight on how to spot and handle the violations of these principles, and also serve as good refactoring practice. And I promise, this is a guaranteed rectangle/square/shape -free post about SOLID.

A Web API & Angular starter project using Azure AD Identity

Published on 3rd August 20153rd August 2015 by Florin

Having worked on a few greenfield projects in the last couple of years I always found myself eager (and sometimes under pressure) to get a good grasp of the domain and start delivering business value from day one.

While this is an ideal scenario, in reality a good part of the first sprint is usually spent setting up the working environment and drafting a high level architecture. And although this how it should be (you don’t want to start coding without some planning), once an architectural and technological path for the project is agreed, I sometimes felt it would be helpful to be able to fast forward through the repetitive parts of this process, especially if it’s something already familiar and proved to be working.

Unit of Work implementation in the context of DDD, using EF and Unity

Published on 26th July 201527th July 2015 by Florin

I’m going to keep the introduction short as I believe the title is pretty self-explanatory but I do want to emphasize from the beginning that the goal here wasn’t to create a ‘One to rule them all’ implementation of the Unit of Work pattern. There is a variety of feature-rich implementations online but before going for the ‘ultimate’ one I would advise following the Yagni principle. Start simple, learn what you need and adapt.

The main goal here is to show how this pattern fits with a DDD mindset and how it can be easily implemented using the technologies mentioned. I will demonstrate this in two popular scenarios:

A web application using ASP.NET Web API – the UI
A console application – the background process