Business Rules - Software Architecture

This document lists the fundamental business rules of the Software Architecture domain, identified with a unique BR-NNN code. Each rule is technology-independent and describes an invariant constraint on the design and evolution of a software system.

---

BR-001 - Every significant architectural decision is recorded in an ADR

Code: BR-001 Name: Significant ArchitecturalDecision are documented as an ADR Description: Every decision affecting the structure, quality attributes or constraints of the system must be recorded in an Architecture Decision Record with context, options considered, decision and consequences. Undocumented decisions are not admitted as architecture. Motivation: Preserve the knowledge of "why" beyond "what"; enable informed evolution. Priority: HIGH Actors: Software Architect, Tech Lead Traceability: glossary "Architecture Decision Record (ADR)"; state-machines/adr-lifecycle.md; BC-01.

---

BR-002 - Architecture is driven by quality attributes

Code: BR-002 Name: Structural decisions derive from prioritised quality attributes Description: The choice of architectural styles and patterns must be justified by the required quality attributes (scalability, availability, maintainability, security). A trade-off between attributes is made explicit; no structural decision is taken merely for technology fashion. Motivation: Align structure to the system's real non-functional goals. Priority: HIGH Actors: Software Architect, Business Stakeholder Traceability: glossary "Quality attribute", "Architecture evaluation (ATAM)"; BR-001.

---

BR-003 - Dependency direction respects architectural boundaries

Code: BR-003 Name: Dependency points inward, never from the inside outward Description: In layered/hexagonal/Clean architectures, the domain does not depend on infrastructure: the dependency arrow goes from the outside toward the domain. A dependency violating this direction is architectural debt to be corrected. Motivation: Keep the domain pure and testable, independent of frameworks and technical details. Priority: CRITICAL Actors: Software Architect, Code Reviewer Violation: ConstraintViolated; the merge is blocked by the dependency fitness function. Traceability: glossary "Clean Architecture", "Hexagonal architecture", "Onion Architecture", "Anti-corruption layer".

---

BR-004 - High cohesion and low coupling between components

Code: BR-004 Name: Every Component maximises internal cohesion and minimises external coupling Description: Responsibilities are grouped by cohesion; interactions between components occur through stable interfaces. A component that changes for many different reasons, or that is too coupled to others, must be redesigned. Motivation: Allow independent evolution and reduce the impact of change. Priority: HIGH Actors: Software Architect, Tech Lead Traceability: glossary "Cohesion", "Coupling", "Bounded context".

---

BR-005 - Technical debt is made visible and managed

Code: BR-005 Name: Every identified TechnicalDebt is recorded, assessed and planned Description: Architectural technical debt (structural shortcuts, pattern violations, deprecated components) is made explicit, assessed for impact and interest, and placed in the backlog. No invisible debt accumulates. Motivation: Avoid the silent erosion of the architecture over time. Priority: HIGH Actors: Tech Lead, Software Architect Traceability: glossary "Fitness function"; events/domain-events.md event TechnicalDebtIdentified; BR-002.

---

BR-006 - Component boundaries follow Conway's Law

Code: BR-006 Name: Component structure is aligned to team structure Description: Decomposition into Component accounts for Conway's Law: software boundaries tend to mirror organisational communication boundaries. Misalignments produce friction and coupling; the inverse Conway maneuver is applied where needed. Motivation: Reduce organisational friction and foster team autonomy. Priority: MEDIUM Actors: Software Architect, Business Stakeholder Traceability: glossary "Conway's Law", "Bounded context".

---

BR-007 - A breaking change requires contract versioning

Code: BR-007 Name: The evolution of an architectural contract preserves consumers or introduces a new version Description: When a Component exposes an API or a contract consumed by others, a breaking change requires a new version and a coexistence period. Deprecation follows an announced path. Motivation: Protect consumers from regressions; allow orderly migrations. Priority: HIGH Actors: Software Architect, Tech Lead Traceability: glossary "API Gateway", "Idempotency"; events/domain-events.md event APIVersionPublished.

---

BR-008 - Architectural conformance is verified by fitness functions

Code: BR-008 Name: Architectural constraints are expressed as automated fitness functions Description: Structural constraints (dependency direction, layering, naming, coupling limits) are encoded as fitness functions run in the pipeline. A violation blocks integration, preventing architecture erosion. Motivation: Make the architecture verifiable and resistant to degradation. Priority: HIGH Actors: Code Reviewer, Software Architect Violation: ConstraintViolated; build failed until the constraint is restored. Traceability: glossary "Fitness function", "Architecture evaluation (ATAM)"; BR-003.