Link: Sacrificial Architecture

Martin Fowler’s new gem is Sacrificial Architecture. Not sure if this makes the same buzz as Microservices did, but reading this article makes me nod all the time.

Essentially it means accepting now that in a few years time you’ll (hopefully) need to throw away what you’re currently building. This can mean accepting limits to the cross-functional needs of what you’re putting together.Knowing that you will throw away (and replace) the code sometime later increases your code’s modularity.

Modular replaceability is a principal argument in favor of a microservices architecture, but I’m wary to recommend that for a sacrificial architecture. Microservices imply distribution and asynchrony, which are both complexity boosters.This is exactly what we’ve discussed in the latest episode of Rebuild, where we started as a microservice/SOA approach but ended up porting back the code into the monolith as an engine. We didn’t intend to scrap the code before even shipping it, but the effort to make the interface as decoupled as possible has paid off, since porting the code didn’t require much of a rewrite in the business logic layer.