Eventual Consistency via Domain Events and Azure Service Bus

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:

Read More

A SOLI[D] refactoring exercise – Part 1

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.

Read More

A Web API & Angular starter project using Azure AD Identity

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.

Read More

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

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

Read More