Organise your Work so You Can Feature Flag it Easily
How to Not Lose your Mind In a Complex System
I recall one of my first encounters with a feature flag. It was a combination of compiler-level constants and file concatenation. Luckily you can still do that today with PHP 🤣
Joke aside, that initial encounter instilled this idea that having a binary check is hackish.
But nowadays we have complex tech to manage the flags.
Now the only thing left is the feature.
Easy, right?
.
..
…
Right?
Where Does a Feature start and Where does it end?
Whatever example I pick you can poke holes into it as the landscape is quite complex. So I’ll choose one to get the basic ideas across and we can drill down into details in the comments.
Let’s go with a typical E-commerce oriented SaaS company.
You serve your business, advertisers, your clients, the employees of those clients and ultimately, end-users who shop at the actual shops.
Clean Architecture and Use Cases make this distinction simple.
The UI sits on top so you can flag it there.
The UI interacts with a specific Use Cases, you can flag it there.
Your Use Cases may flow through a common gateway, you can flag its route or event.
However, most applications on the web are a mess an intricate mesh of API calls and partial UI Components. A web application following such a patterns lacks an important quality: your features have to be vertical by structure.
Making Features “Vertical” - Which way is up?
Vertical Slice Architecture (VSA) is hard to grasp for a few. Perhaps there’s something language-specific in it that as of yet avoids my understanding.
VSA can be trivialised to a few rules:
Each vertical is a cohesive feature. Yes, that’s the S- and O- from SOLID principles.
Modules and logic within a vertical should not touch, modify or import domain or application logic from other verticals
Duplication is preferred to maintain isolation for simple cases
The vertical slice should appear on the top level of the project’s folder structure
Branch By Abstraction
Branch by Abstraction by Paul Hammant follows a similar idea. There are very good examples on the website, I suggest you check them out after you’re done with this article.
Here’s my highway example
BBA is for sunsetting old features with new ones or exploring 2 options in parallel. Imagine you are repairing a highway lane or bridge. Here’s a few steps to highlight it:
Designate a slice of the lane to be used for “construction purposes”
Establish routing that you can toggle so you can bypass main construction (this is your feature flag, but before anything is being built)
Start building the new site
Once functional, toggle the routing to it
Now start working on the old site
Optional: It’s likely you’ll have to clean up both sites afterwards, so you may need to toggle back
Remove the routing, keeping the new sites only
Disclaimer: I never worked in construction. Roast me in the comments.
The routing is essentially a combination of Ports and Adapters from Hexagonal Architecture.
Valetina runs the Optivem Journal and has an excellent summary of it 👇
.
You can buy and explore Paul’s book on trunkbaseddevelopment.com (what a great domain name!)