Skip to content
    Architecture & organization designChapter 14

    The Boundaries of Reuse

    When reuse reduces complexity and when similar-looking requirements should remain separate, illustrated through forms and other engineering contexts.

    Original guideworking20 minevergreen · reviewed Aug 13, 2026
    Tech Lead
    Staff+
    Chapter outline

    Brief

    The essential idea

    Reuse is valuable only while it lowers total system complexity. Similar functional requirements can hide very different quality attributes: a customer form optimizes speed, usability, and security; an agent form needs more flexibility; an internal form may accept complexity in exchange for power. Forcing them into one universal builder can centralize conflicting requirements rather than eliminate duplication.

    A sound reuse decision compares semantics, bounded contexts, non-functional requirements, change cadence, compatibility contracts, ownership, and six-to-twelve-month economics. A small reusable kernel with context-specific adapters is often safer than a universal layer, and the boundary must be revisited when the cost of change begins to rise.

    Decision lens

    Key takeaways

    Functional similarity does not prove that two solutions belong to the same architecture.

    Non-functional requirements are often the decisive difference between superficially similar cases.

    Shared DTOs, services, pipelines, runbooks, and authorization policies can couple domains with different meanings and risk profiles.

    Good reuse requires stable contracts, explicit ownership, and a lower support cost than maintaining separate implementations.

    Premature generalization creates a global change surface before a stable usage pattern exists.

    Context optimization is usually more reliable than a universal solution designed for every future case.

    Workplace experiment

    Apply it at work

    1. 1

      Compare the quality attributes and change cadence of candidate reuse cases before comparing their feature lists.

    2. 2

      Document the bounded context, ownership, compatibility policy, and six-to-twelve-month economics of the shared layer.

    3. 3

      Separate a minimal reusable kernel from context-specific adapters instead of sharing the entire stack.

    4. 4

      Add a reuse decision log and review the boundary when lead time or integration failures increase.

    5. 5

      Stop one premature abstraction until at least two stable, genuinely compatible use patterns are visible.

    Choose one action, define the observable effect, and keep the first test small enough to reverse.

    Evidence

    Sources and further reading

    Additional sources

    Channel, aggregator, and commentary links confirm the work; they are not the primary source.

    Previous chapterOrchestration and Choreography for TeamsNext chapterDesigning Team Structure Around Business Requirements