El Diagrama de Tensión de Componentes

REP, CCP y CRP forman un triángulo de tensión. Satisfacer los tres simultáneamente es imposible — cada par excluye al tercero:

• REP + CCPignora CRP — los componentes crecen con clases que algunos usuarios nunca necesitan.
• REP + CRPignora CCP — un único cambio de funcionalidad se propaga por muchos componentes, cada uno requiriendo su propia publicación.
• CCP + CRPignora REP — los componentes no se rastrean ni publican correctamente, haciendo la reutilización impráctica.

La posición dentro de este triángulo de tensión debe cambiar a medida que el proyecto madura. Al inicio del desarrollo, el equipo cambia frecuente y ampliamente — CCP debe dominar para minimizar el número de componentes que deben cambiar juntos. A medida que el proyecto madura y usuarios externos empiezan a depender de sus componentes, REP y CRP se vuelven más importantes. Sobre-diseñar la estructura de componentes para reutilización antes de que el diseño sea estable genera más sobrecarga de publicación que valor.

Over-splitting too early — before the design is stable — means a single feature change cascades through many packages, consuming release time instead of development time.

# Young startup: 20 micro-packages created from day one to satisfy REP/CRP.
# Adding "discount to order" requires:
#   - bump order_core v0.3.0
#   - bump order_events v0.2.1
#   - bump pricing_rules v0.4.0
#   - bump discount_engine v0.1.2
#   - bump cart_service v0.5.0
#   - bump checkout_api v0.8.1
#   - bump notification_hooks v0.3.0
# 7 release PRs, 7 CI pipelines, 7 version pins to update.
# The team spends more time on releases than on features.

// 20 packages created on week 1 of the project:
// @app/order-core, @app/order-events, @app/pricing-rules,
// @app/discount-engine, @app/cart-service, @app/checkout-api,
// @app/notification-hooks, @app/user-profile, @app/address-book ...

// One product requirement touches 7 packages.
// Each needs its own semver bump, changelog, and npm publish.
// Teams block each other waiting for upstream packages to release.

Four coarse packages aligned to change boundaries (CCP-first). One feature change touches one or two packages — extract finer packages only once stable reuse patterns emerge.

# order/          — all order domain logic (changes for same reason)
# pricing/        — discount + tax rules (change per finance requirements)
# checkout/       — cart + payment flow (change per UX requirements)
# notifications/  — email/SMS (change per marketing requirements)

# Adding discount touches order/ and pricing/ — two releases, not seven.
# As patterns emerge and external reuse grows, further splitting is justified.

// Four coarse packages aligned to change boundaries (CCP first):
// @app/orders       — order domain; changes with order requirements
// @app/pricing      — tax + discount logic; changes with finance requirements
// @app/checkout     — cart + payment flow; changes with UX requirements
// @app/notifications — email/SMS; changes with marketing requirements

// As the codebase matures and reuse patterns become clear,
// extract finer packages guided by REP and CRP — not before.