One feature, five layers
A single shape for features: view, use case, repository, service, adapter.
Context
Censhare's product is built from many modules by several people. Every module has to fetch data, hold state, apply rules and draw a screen, and without a shared shape each one answered those questions its own way.
Reviewing a change meant first working out how that particular module happened to be organised.
Options considered
| Option | For | Against |
|---|---|---|
| Let each module choose its own structure (rejected) | No coordination; every team moves at its own pace. | Modules behave differently, and what someone learns in one does not carry over to the next. |
| Components that fetch data and make decisions themselves (rejected) | Fewest files and the quickest start. | Network calls and business rules are tangled into rendering, so they can only be tested through the UI. |
| Five layers (view, use case, repository, service, adapter) (chosen) | Each layer has one job and can be tested on its own. Calls only go downwards. | More files per feature, and some indirection for very small screens. |
Decision
Features are built in five layers, view, use case, repository, service and adapter, each with one job and calls that only go downwards.
Consequences
Better
- It is now the standard in 13 product modules.
- Because each layer can be tested on its own, the cause of a production bug is usually found within a day instead of several days.
- Every piece of a feature has an obvious home, so reviews start from a shared map.
Harder
- Small features carry a little more ceremony than they strictly need.
- New team members have to learn the layers before they are fully productive.