Separation of concerns

What it means

Separation of concerns keeps different reasons for change from being unnecessarily mixed. In an application, parsing, policy, persistence, presentation, and operational handling may be separate concerns even when they participate in one workflow. The goal is understandable responsibility, not a rigid number of layers.

Example

A command handler validates input, applies pricing rules, writes a record, and formats an HTTP response. Separating policy from transport lets the pricing behavior be tested without a web server.

Limitations

Too much separation can create indirection and coordination overhead. Concerns also interact, and forcing a boundary where the domain is naturally coupled can make the design less clear. Use change history and reasoning cost as evidence.

How to use the signal

The best split is the one that keeps important decisions close to their owner while making cross-cutting effects explicit.

Use reasons for change and ownership to choose boundaries, instead of enforcing a fixed number of layers.

Weave can help identify whether a separation refactor changes review iterations or rework. Use Weave’s workflow signals alongside code ownership and dependency analysis.