Software architecture is not a diagram of boxes. It is the set of boundaries that determine where behavior lives, which parts depend on which others, and how much of the system must change when a requirement changes.
Organize around reasons to change
A module is cohesive when its responsibilities belong together. Coupling describes how much one module knows about or relies on another. A design with low coupling and clear cohesion can isolate a change, but splitting every function into a separate service does not automatically improve either property. Communication, deployment, observability, and failure handling become part of the dependency too.
Dependency direction is an explicit choice. If a business rule imports a database client directly, the rule depends on storage details. An interface at the boundary can let an outer adapter implement the operation while the core policy depends only on the contract. This is useful when substitution, testing, or independent change matters; the abstraction also has a maintenance cost.
Patterns name recurring moves
Strategy makes a family of algorithms interchangeable. Adapter translates one interface into another. Observer distributes notifications to subscribers. These patterns are tools for a specific pressure, not mandatory layers to add to every program. A pattern helps when it clarifies a boundary and makes a real change cheaper; it hurts when it hides simple control flow behind indirection.
Make the decision reviewable
For a design choice, write the requirement, constraints, alternatives, failure cases, and the reason one option was selected. Name the cost you accept. Revisit the choice when constraints change rather than treating the first decision as permanent truth.
Refactoring.Guru's Strategy pattern guide gives a concrete example of isolating interchangeable behavior; the same reasoning applies to larger module boundaries.