Designing for change with Vertical Slice Architecture - Chris Sainty - NDC Oslo 2024

Vertical Slice Architecture organizes code by feature/capability rather than technical layers, leading to better maintainability and less coupling between components

Code sharing between features should be approached cautiously - duplication can be cheaper than wrong abstractions and tight coupling. Only share code after seeing 3+ identical use cases

Features should be self-contained with everything needed to fulfill that feature’s requirements, making them easier to understand, modify and delete without affecting other parts of the system

Services often become a source of coupling and complexity - they tend to grow large, have multiple responsibilities, and create dependencies across features

Each feature should have exactly one reason to change and be optimized for its specific use case rather than trying to be generic and reusable

Commercial pressures and rushed features are inevitable - vertical slice architecture helps manage technical debt by containing it within feature boundaries

New features can be built alongside existing ones in separate slices, making it easier to do A/B testing or customer-specific implementations

Developer onboarding becomes easier as engineers can focus on individual features without needing to understand the entire system

The architecture supports gradual migration - you can start with new features in vertical slices while leaving existing code as-is

The true test of an architecture is how well it handles change over 3-5+ years, not just the initial development period