General guidelines for cross-cutting concerns

Principle · Chapter 9

Guidelines architects follow when designing solutions for cross-cutting concerns.

Identify cross-cutting concerns

First step: recognize common functionality repeated across modules and layers.
Abstract it so it isn’t duplicated. Sometimes the logic is identical across usages; sometimes refactoring is needed to make it generic and reusable.

Before building in-house, check whether a capable solution already exists.
Example: logging — mature frameworks already provide the needed functionality, so don’t reinvent the wheel.

Each concern should behave the same way everywhere it is used.
Consistency is a core reason not to duplicate a cross-cutting concern’s implementation.

Scattering = adding the same functionality to every consuming class that needs it (copy-paste).
Violates Don’t Repeat Yourself (DRY). Duplicated code is wasteful, harder to keep consistent, more complex, and larger.
A change to duplicated logic must be made in every copy.

Tangling = mixing cross-cutting logic with logic for a different concern (core or another cross-cutting).
Violates Separation of Concerns and leads to low cohesion, higher complexity, lower maintainability.
Countermeasures:
- Keep cross-cutting logic loosely coupled with the code that uses it.
- Single Responsibility Principle (SRP): a class should have one reason to change; a class owning a core concern shouldn’t also implement a cross-cutting concern.
- Open/Closed Principle (OCP): add cross-cutting behavior by extending a component with new code, without modifying existing business logic.

These guidelines lean on Following SOLID design principles (SRP, OCP) and Minimizing complexity (DRY).
Implementation approaches that satisfy these goals: Implementing cross-cutting concerns.

Software Architect’s Handbook (Packt, 2018), Ch.9 “General guidelines for cross-cutting concerns”, pp. 693-698.