Comparison
Package by featurevsScreaming architecture
Package by feature
one change touched one folder, instead of the same change touching the controllers, services and repositories folders.
Grouping code by the capability it serves rather than by its technical role, so a feature's handler, model and storage live together. It aligns the physical structure with the direction changes actually arrive from, and it makes package-private visibility useful again because a feature can hide its internals. Packaging by layer optimises for the rarer case — swapping an entire technical layer at once.
Full entry →Screaming architecture
you opened the top-level folder and learned what the system does, rather than which framework it was written in.
The argument that a codebase's top-level structure should announce its domain — billing, shipping, catalogue — rather than its technical layers. It is a memorable statement of package-by-feature and a direct criticism of a repository whose root contains controllers, models and services. Its practical payoff is that a change to one capability touches one folder.
Full entry →