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.