Use Case x Clean Architecture x Vertical Slices
Despite its non-standard name, a common industry pattern
A short post today. The trio above is my preferred approach towards all software applications for the web.
Ground Rules
Clean Architecture separates technical layers from business ones
Vertical Slices combine a subset of these three layers (like slicing a cake)
Use Cases combine several slices
But first, let’s talk about modules
In terms of a cohesion a module is piece of code that is coupled together locally, and decoupled from its neighbours.
Better yet, a folder of dependent classes that have no outside dependencies.
What is and isn’t a module is often a misnomer.
Vlad Khononov has a great talk on the formulation of complexity and coupling in the talk below using terminology that is compatible with software concepts and Domain-driven design
The Business of Business
When we make changes that are technical in nature, changes often only touch one layer and slice of modules in a well-architected system. Changes such as:
Changing the version of a JSON library
Bumping a React plugin
Adding a column to a database
Adding more logging
Exposing API versions
However, changes to the behavior of the system motivated by new business requirements are almost exclusively cross-cutting. This presents a challenge to developers on how to prioritise the main axis of their folder structure: features or technical capabilities?
The Combination
It is the interplay between purely technical and business challenges that gives rise to the productivity boost of using more vertical-oriented architectures. It goes hand-in-hand with context mapping enabled by Domain-driven Design.
Milan Jovanović highlighted in our conversation on the Technologist Podcast that team members often praise projects that are organised around these rules — or at least those that are vertical first. Because they are much easier to work on. And much simpler to understand.