15.3 · Feature modules and boundaries, and strangling a legacy codebase

Boundaries are the part of architecture that outlives any pattern. Where you put them decides what teams can change independently, and how you can retire the old code.

Mental model. A boundary is a small public surface with a hidden inside. Draw it where change is expected, then move code behind it a piece at a time.

Boundaries

Feature modules and who owns what.

1. What is a feature module, how do you draw module boundaries, and how does access control enforce them? 15.3.1 · L3
   A feature module packages one product area (checkout, profile, search) as its own target or Swift package with a deliberately small public interface: typically…

Migration

Strangler patterns for old code.

1. How do you migrate a large legacy codebase safely: the strangler pattern, adapters and characterization tests? 15.3.2 · L5
   Rewriting a working app from scratch usually fails: it takes longer than planned, must keep up with a moving target, ships nothing until the end and loses…

More in Architecture & API design

• 15.1 · MVC, MVVM, MVP, VIPER, RIBs, TCA and Clean, and unidirectional data flow
• 15.2 · Coordinators, routers and dependency injection
• 15.4 · throws, Result, typed throws and mapping errors at boundaries
• 15.5 · Designing a Swift API: naming, ownership, documentation and evolution
• 15.6 · SOLID without dogma, and building a platform for many apps
• 15.7 · Effects and cancellation, modelling state, composing reducers
• 15.8 · Closure-based clients, dependency lifetimes, generic repositories and building the graph lazily
• 15.9 · Binary breaks from innocent changes, and what an import exposes
• 15.10 · Types that prevent misuse, error types for libraries, one-shot values and when to trap