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.