An architecture-focused essay explores how to organize codebases around business features rather than technical layers, using the lens of cognitive load theory (coined by John Sweller in 1988). It traces the pendulum swing from technology-centric layered architectures to feature-based vertical slices, arguing both extremes fail without careful boundary management. The piece introduces 'Fractal Architecture' as a middle path, where modules at every level (feature, module, system) share the same repeating pattern of explicit dependencies and exposed capabilities, illustrated with TypeScript code examples for an e-commerce order/shopping-cart system. It references Mark Seemann's book 'Code That Fits in Your Head' and the C4 model for architectural visualization.
Questions this post answers
What is fractal architecture in software design?
Fractal architecture is a way of structuring software so the same pattern of explicit dependencies and exposed capabilities repeats at every level, from a single feature up through modules and whole systems. Each unit declares what it needs from the outside world and what it exposes, so features, modules, and systems can be composed the same way, similar to nested folders like verifying-order inside orders inside e-commerce inside an ERP system. See more takes on organizing large codebases around business features on daily.dev.
What is cognitive load in the context of software architecture?
Cognitive load, a term coined by John Sweller in 1988, describes how working memory can hold only a small amount of information at once, so instructional methods and, by extension, code structure should avoid overloading it. Applied to software, this means organizing code so a developer does not need to hold the entire system in their head to understand or change a single feature. Developers weighing architecture patterns against team cognitive limits can find more discussion on daily.dev.
What are the downsides of splitting a codebase purely by vertical feature slices?
Pure feature-based splits without any grouping tend to produce a maze of duplicated code and hidden coupling, because teams focus narrowly on individual features without understanding the bigger picture or why a feature was added. This mirrors the earlier failure of pure technical-layer splits, where teams optimized for output rather than the underlying business outcome. Anyone debating vertical slices versus layered design can track more architecture perspectives on daily.dev.