Design patterns

Dogmatic over-use of patterns can be pretty harmful. That said, it is helpful to be equipped with a general awareness of how other people have solved problems before you…

May 24th, 2019

Architecture patterns to support incremental change

People tend to see architectural change as a big transactional effort, so if any mistakes are made they tend to be huge mistakes. It is better to focus on delivering smaller changes that can demonstrate incremental value.

January 6th, 2019

Finding service boundaries: more than just the bounded context

When you are identifying service boundaries, it’s not enough to consider the domain model alone. There are other, more pragmatic concerns to bear in mind.

November 27th, 2018

Writing ArchUnit style tests for .Net and C# to enforce architecture rules

ArchUnit is a java library that provides a fluent API for creating self-testing architectures via unit tests. A similar library can be written for .Net Standard that acts on compiled assemblies rather than raw code.

October 12th, 2018

Message design anti-patterns for event-driven architecture

Event-driven integration can improve the scalability, resilience and scalability of distributed applications… but this does depend on the design of your event messages…

August 12th, 2018

Building Twelve Factor Apps with .Net Core

Twelve factor apps provide a methodology for building apps that are optimised for modern cloud environments. It’s only been achievable in the Microsoft world since the advent of .Net Core.

July 29th, 2018

Autonomous bubbles and event streams: Pragmatic approaches to working with legacy systems

It’s easy to get caught up in unrealistic notions that you can re-write a legacy system or gradually decompose it. There are other, more pragmatic approaches that can help to modernise architectures and enable new development.

June 18th, 2018

Using architectural “fitness functions” as a guide to system design

Fitness functions can be a useful metaphor for guiding an emerging architecture, but you do have to invest in making sure they describe the right outcome.

June 3rd, 2018

Layers, onions, hexagons and the folly of application-wide abstractions

Not only are layered applications difficult to maintain, but the common abstractions they are built on tend to give rise to inflexible implementations that have serious scalability challenges.

July 22nd, 2017

The poor man’s Cassandra: scaling Azure Table Storage to maximise throughput.

Azure Table Storage can be tuned for high throughput workloads, but you’ll probably be faced with some difficult trade-offs.

February 12th, 2017

A simple guide to using Redux with React.js (yeah, right…)

Learning React.js always starts so well, but adding Redux into the mix can make things unnecessarily complex. The lack of accessible examples doesn’t help – this is an attempt at writing a stripped down, bare bones introduction that focuses on the main ideas behind Redux.

January 7th, 2017

Event stores and event sourcing: some practical disadvantages and problems

Event stores and event sourcing are a powerful idea, but they can be vulnerable to a number of technical and operational challenges when faced with real world complexity.

October 27th, 2016

The problem with using maturity models to describe technology solutions

Maturity models are a management tool. When applied to technology solutions they often provide a weak analysis that describes a false progression.

October 3rd, 2016

What’s so bad about monoliths anyway…?!

Don’t get me wrong – I am an advocate of decomposing functionality into autonomous services. My reservation is that you need to have a lot of prerequisites in place before you can start leveraging microservices.

July 29th, 2016

Designing an event store for scalable event sourcing

Event sourcing can scale very nicely, though this does depend on a number of key design decisions for the underlying event store.

June 2nd, 2016

Is “Serverless” architecture just a finely-grained rebranding of PaaS?

Serverless computing makes bold promises of development without having to worry about environments, scaling or deployment. Haven’t we been here before?

April 14th, 2016

What do we actually mean when we say “business logic”?

In most cases “business logic” just refers to the poorly-defined “gloop” that sits between user interfaces and databases in layered architectures.

March 23rd, 2016

API gateways and the dangers of creeping middleware scope

An API gateway can solve many generic problems in an API infrastructure, but you do need to define a clear remit and protect against creeping scope.

July 25th, 2015

Can cross-cutting concerns really exist between services?

You might be able to identify cross-cutting concerns in a monolith, but in a service-orientated world they should melt away into specific implementations.

May 5th, 2015

Refactoring large monoliths to microservices: strategies, risks and pragmatic reality

Large scale rewrites of systems are loaded with risk. You can address this by preparing the ground in advance and adopting an incremental approach, but a willingness to be pragmatic is essential.

March 9th, 2015

How big is a microservice?

We know that micro services are small and focused by design – just how small is this in practice?

February 8th, 2015

Protocol buffers for .Net: protobuf-net vs protobuf-csharp-port

Google’s open source serialization format is an efficient way of passing platform-independent and version-tolerant data between end-points. Two very different implementations have emerged for .Net.

November 3rd, 2014

Why you shouldn’t create asynchronous wrappers with Task.Run()

Many developers confuse asynchronous operations with parallel execution. The essential difference is that an asynchronous operation is concerned with which resources you consume while parallel execution is more concerned with how many.

September 9th, 2014

CQRS is a state of mind rather than a cookie-cutter design pattern

CQRS is based on the simple notion that you use a different model to update information than the one to read it. This does not necessarily have to give rise to the same solution every time.

July 9th, 2014

The problem with tiered or layered architecture

An architecture based on tiers or layers is too inflexible to deal with the more flexible demands of modern systems, particularly when you working with high-volume systems that require distributed processing.

June 12th, 2014

Are microservices just SOA “done properly”?

There’s nothing really new about many of the ideas that underpin microservices. Are they just an agile re-branding of SOA?

May 4th, 2014

Eventual consistency and the trade-offs required by distributed development

Developers who have been brought up on the certainties of ACID transactions often have a problem trusting eventual consistency. Once you start exploring the requirements in more depth this really so much of a handicap.

January 13th, 2014

Identifying the sources of system coupling in service orientated architectures

Every system has some level of coupling. After all, systems need to collaborate and in doing so they will inevitably share some characteristics of language and behaviour. It’s important to recognise where coupling occurs and the impact it has on stability and flexibility.

October 19th, 2013

Can APX help in developing usable and accessible APIs?

Given how important APIs have become in driving the reach of applications and services, it’s surprising how little investment is made in the usability of APIs as opposed to UIs. Perhaps the principals and techniques used by UX should be applied to developing more effective APIs…

July 16th, 2013

Managing change and version control for service interfaces

Change is an inevitable and even desirable part of distributed development. Managing the impact of that change is the difficult part, particularly when change affects the service interfaces that bind a distributed platform together.

June 17th, 2013

Netflix has abandoned OData – does the standard have a future without an ecosystem?

Netflix have closed their OData catalogue and EBay seem to have quietly put their implementation out to grass. With a shrinking ecosystem and no marquee services, does Microsoft’s data standard have a future?

May 21st, 2013

The generic repository is just a lazy anti-pattern

A generic repository is often used with the entity framework to speed up the process of creating a data layer. In most cases this is a generalization too far and it can be a trap for lazy developers.

February 22nd, 2013

A shared database is still an anti-pattern, no matter what the justification

Shared databases risk turning into performance bottlenecks that encourage close-coupling and create a single point of failure. There’s no justification for using them to integrate processes and applications.

December 17th, 2012

REST services may not have standards, but they should follow conventions

REST is more of an architectural style than a set of standards. That said, a service should follow certain conventions if it is to be predictable and simple to work with.

November 6th, 2012

Are CRUD methods what we really want from a repository?

CRUD-based repositories may appear convenient but they can make for poor service interfaces as well as giving rise to a lot of unnecessary boiler-plate code.

July 2nd, 2012

How not to use dependency injection: service locators and injection mania.

Development teams can struggle with dependency injection, often because they don’t have a clear understanding of how best to use it.

January 8th, 2012

Entity Framework anti-patterns: How not to use an ORM with SQL Server

The Entity Framework has come a long way since its earliest incarnations prompted a vote of no confidence from the development community. However, like any data access technology, there are still a number of traps for the unwary – particularly if you’re using it in a tiered application.

September 9th, 2011

EPiServer CMS anti-patterns: common mistakes in development projects

EPiServer is a great CMS but like all platforms it has a number of traps for the unwary and inexperienced.

December 12th, 2010

Exception safety in C# – more than just trying and catching

Exceptions can be a very effective means of handling errors in a systematic way, but using them properly can be a pretty delicate operation. If they are not handled properly then they can become a source of leaking resources, partially-completed operations and inconsistent data.