In Robert C. Martin's component-cohesion tension diagram, the Common Reuse Principle (CRP) pulls against the Reuse/Release Equivalence Principle (REP) and the Common Closure Principle (CCP). Explain the tension and how you would choose a position for a given project.

## The three vertices - **REP — Reuse/Release Equivalence Principle:** "The granule of reuse is the granule of release." To be reusable, a component must be tracked by a release process: a version number, release notes, a documented public surface, a compatibility promise. Consequence: things you want reused together must be released together, which *groups* classes into larger components. - **CCP — Common Closure Principle:** "Gather into components those classes that change for the same reasons and at the same times." This is SRP for components. It minimises the number of components a maintainer must modify, revalidate and release for one requirement change — which also *groups* classes into larger components. - **CRP — Common Reuse Principle:** "Don't force users of a component to depend on things they don't need." This is ISP for components. It *splits* components. ## The tension diagram Draw a triangle with REP, CCP, CRP at the vertices. Each **edge** is labelled with the price you pay for ignoring the vertex opposite it: - Focus on **REP + CRP** (ignore CCP): components are small, well-versioned and lean for consumers — but a single requirement change now touches many components, so **too many components change** for one change, and every change means multiple coordinated releases. - Focus on **REP + CCP** (ignore CRP): components are big, coherent and stable to release — but consumers get dragged along, so there are **too many unneeded releases** for them to absorb. - Focus on **CCP + CRP** (ignore REP): boundaries are pragmatic for both change and usage — but nothing is properly versioned or released, so the components are **hard to reuse**: no version guarantees, no notes, no compatibility promise. Where your architecture sits inside the triangle *is* your component strategy. Sitting exactly at a vertex is always wrong; you are choosing which of the three costs you can currently afford. ## Choosing a position: the lifecycle argument Martin's key observation is that the right position **moves over time**. **Early project / few or no external consumers.** Developability dominates. Nobody is reusing your components yet and requirements churn weekly. Sit near **CCP**: fewer, fatter components; a change lands in one artifact; you avoid the coordination tax of splitting. CRP violations are cheap because there are barely any consumers to inconvenience. **Mature project / many consumers / stable code.** Reusability dominates. Now every irrelevant release costs N teams their integration time, and the dependency closure is bloating everyone's builds. Drift toward **REP + CRP**: split along real joint-usage lines, publish per-capability artifacts, take semantic versioning seriously. **The migration is the hard part** and should be planned, not improvised: 1. Gather evidence: which consumers use which classes (build-graph analysis, import scanning, telemetry on published API usage). 2. Cluster by observed joint usage, not by aesthetic taxonomy. 3. Split physically, then keep the **old artifact as a thin aggregator** that depends on the new ones and re-exports, so nothing breaks on day one. 4. Deprecate the aggregator with a stated window; migrate consumers; delete. ## Additional inputs to the decision - **Consumer count and diversity.** One consumer: CRP is nearly irrelevant. Fifty consumers using disjoint slices: CRP dominates. - **Change frequency and its distribution.** If change is concentrated in one cluster, splitting that cluster out protects everyone else. - **Release cost per consumer.** Regulated or certified environments make each irrelevant release very expensive, so CRP's weight goes up. - **Build topology.** A monorepo with atomic builds erases most of CRP's cost; independent repos with published artifacts maximise it. - **Artifact-count budget.** Every published component has fixed overhead: pipeline, ownership, docs, deprecation policy. Beyond some count, coordination cost outweighs the CRP savings. - **Coupling principles interact.** Splitting to satisfy CRP adds edges to the component graph; you must still satisfy ADP (no cycles) and SDP/SAP (depend in the direction of stability). A careless CRP split can create a cycle between the two new components — which usually means you split along the wrong seam, or need to extract a shared abstraction component. ## Interview framing "There's no optimum, only a chosen trade-off. Grouping forces — REP and CCP — make components bigger for maintainer and versioning convenience; CRP is the only splitting force and it protects consumers. Which cost you can afford depends on how many consumers you have and how expensive their integration is, and that changes as the system matures — so I treat component boundaries as reviewable, with a migration path via an aggregator artifact rather than a big-bang split."