Clean vs. Vertical Slice

Reconciling dependency direction with feature organization — study notes from Steve Smith (Ardalis).
From Steve Smith (Ardalis): “Nick Chapsas Is Right About Clean Architecture (Mostly)”
Source video — study notes and quiz below

Core architecture concepts

Clean and Vertical Slice address different dimensions — not opposing forces.

  • Clean Architecture (true intent): About dependency direction — protecting business logic from external dependencies, isolating infrastructure, and enforcing boundaries. Not defined by folder structure or a fixed number of projects.
  • Vertical Slice Architecture: Organized around features rather than technical layers. When implementing a feature (e.g. Orders), UI, logic, and endpoint-specific types stay contextually close together.
  • The coexistence myth: These patterns are not opposing. Feature organization answers where to find code; dependency management answers what is allowed to depend on what.

Evolution of .NET project layouts

  • The over-engineered era: .NET solutions often grew into heavily layered templates (6+ projects, sometimes hundreds). Developers hopped through multiple projects just to complete a single feature.
  • The minimal shift: Steve Smith’s “Minimal Clean” template — inspired by Minimal APIs — collapses technical layers into fewer projects (even a single web project) while maintaining strict architectural boundaries.
  • LLM & developer locality: Grouping related elements together reduces scrolling friction for humans and gives AI coding agents a more consistent, discoverable context.
Classic Clean Architecture relied on multi-project solutions to physically enforce boundaries. Minimal Clean consolidates into fewer projects and uses namespaces, folder scoping, or dependency checkers instead.

The rise of modular monoliths

  • Microservices fatigue: Many organizations adopted microservices for team boundaries, not technical scale — then paid an operational tax in network hops and distributed complexity.
  • Modular monoliths: Group code around distinct business capabilities (billing, reporting, user management) with strict boundaries and public contracts inside a single deployable unit or monorepo.
  • Pragmatic boundaries: Modules stay autonomous but co-located — easy navigation, independent feature scaling, and a clean path to microservices only when a true technical need arises.
Jumping straight to microservices enforces boundaries via network isolation. A modular monolith achieves the same encapsulation with language features inside one executable — skipping the operational tax until distribution is actually required.

Quick recall quiz

Quick recall

Five questions on Clean vs. Vertical Slice from the video notes.

Question 1 of 5
According to Ardalis, what is the fundamental core purpose of Clean Architecture?
Enforcing a strict folder structure from 2018
Splitting every application into at least 6 separate .NET projects
Managing dependency direction, isolating infrastructure, and protecting business logic
Ensuring MediatR is utilized for all internal command dispatches
Question 2 of 5
Which architectural dimension directly answers the question: “Where do I find the code?”
Dependency management
Feature organization
Code reuse
Infrastructure isolation
Question 3 of 5
What technical debt did traditional, deeply layered architectures introduce when adding a single feature?
Project hopping and constant directory scrolling to update UI, Business, and Data layers
Incompatibility with Entity Framework Core
Forced migration to cloud-native microservices
Failure of compiler-level dependency validation
Question 4 of 5
Why does keeping a system inside a modular monorepo benefit modern AI-driven development agents?
AI agents cannot interpret distributed network calls
Locality and structural consistency allow LLMs to discover relevant context and generate accurate code
AI agents only function if code is written inside a single project file
It eliminates the need for compilation tools like RipGrep
Question 5 of 5
What is a primary reason organizations reach for microservices when a Modular Monolith could suffice?
Microservices inherently run faster
To solve organizational/team separation problems rather than strict technical scaling requirements
Because Entity Framework does not support shared databases
Microservices eliminate the need for domain boundaries
Result:

Question 1/5
Check-in complete

You finished the architecture recall quiz.

0/5 Correct
Review the concepts tabs and try again when ready.

Study tools

Flashcards

Click or press Enter to flip.

Reflection

  1. Feature organization vs. dependency management: Feature organization is where files live and how intuitive navigation is to a complete use case. Dependency management is compile-time reference rules (e.g. Core must not reference Entity Framework). You can have great feature organization while violating dependency rules.
  2. Shared DB context in vertical slices: Why not duplicate domain models and DB context in every slice? Central shared infrastructure ensures consistency; duplicating database logic per slice causes maintenance fatigue and architectural drift.
  3. Minimal Clean as middle ground: Classic Clean used multi-project boundaries; Minimal Clean collapses into fewer projects and enforces boundaries via namespaces, folder scoping, or dependency checkers instead.
  4. Microservices as anti-pattern: When strong module boundaries and public contracts are the goal, network-isolated microservices add latency, failure points, and serialization cost — a modular monolith achieves the same decoupling in-process.
  5. Architecture for LLM tools: High code locality (endpoints, validators, commands, mappings in cohesive feature folders) gives humans and AI agents immediate context. Structural consistency across modules helps LLMs generate accurate code without hallucinated layouts.