Design Software Boundaries

Answer the decision from evidence, not a pattern name. State the operation, data ownership, runtime/deployment model, quality-attribute scenarios, team and consumer boundaries, state/failure model, and expected evolution. Trace one representative operation in an existing system before proposing a replacement.

Compare the smallest viable structure with only relevant alternatives. For each, state the quality attribute improved, cost, assumptions, ecosystem support, simpler alternative, overuse failure, and how to test, observe, and migrate it. Prefer platform and framework facilities before custom infrastructure. A module, direct call, native state mechanism, or sequential function chain is the default until an independently deployed, versioned, concurrent, durable, or untrusted boundary proves otherwise.