Business Rules - Microservices

This document lists the fundamental business rules of the Microservices domain, identified with a unique BR-NNN code. Each rule is technology-independent and describes an invariant constraint on the distributed-services architecture.

---

BR-001 - A service owns its own data

Code: BR-001 Name: Every Service is the sole owner of its own datastore Description: No service directly accesses another service's database. Data sharing happens only through the owning service's public API or events. This guarantees loose coupling and deploy autonomy. Motivation: Prevent hidden coupling at the schema level; enable independent evolution. Priority: CRITICAL Actors: Service Owner Violation: cross-database access detected in code review → merge rejected. Traceability: glossary "Loose Coupling", "Polyglot Persistence", "Bounded Context"; BC-01.

---

BR-002 - Idempotency of message consumers

Code: BR-002 Name: Every handler of a BrokerMessage must be idempotent Description: Since brokers typically guarantee at-least-once delivery, the same message can arrive multiple times. The consumer must produce the same effect across duplicate deliveries, deduplicating by message key. Motivation: Avoid duplicate effects (double charge, double creation) in the presence of retransmissions. Priority: HIGH Actors: Service Owner, Service Mesh Traceability: glossary "Idempotency", "Dead Letter Queue (DLQ)", "Outbox Pattern".

---

BR-003 - Synchronous communication protected by Circuit Breaker

Code: BR-003 Name: Every synchronous cross-service call is protected by a CircuitBreaker Description: Synchronous calls between services must pass through a circuit breaker with an explicit timeout. When the error rate exceeds the threshold, the circuit opens and calls fail fast with an optional fallback, preventing resource exhaustion. Motivation: Avoid cascading failure where a slow service brings down the whole system. Priority: CRITICAL Actors: Service Owner, Service Mesh Violation: an unprotected synchronous call is flagged as a resilience anti-pattern. Traceability: glossary "Circuit Breaker", "Fault Tolerance", "Resilience", "Bulkhead"; state-machines/circuit-breaker-lifecycle.md.

---

BR-004 - Distributed transactions handled via Saga

Code: BR-004 Name: A transaction spanning multiple services is realised as a SagaTransaction Description: There are no distributed ACID transactions. An operation involving multiple services is a sequence of local transactions with compensating actions for each step, coordinated via orchestration or choreography. On failure, the compensating rollback is executed. Motivation: Guarantee eventual consistency without distributed locks. Priority: HIGH Actors: Saga Orchestrator, Service Owner Traceability: glossary "Saga", "Eventual Consistency", "Orchestration", "Choreography"; workflows/saga-transaction.md.

---

BR-005 - Mandatory registration and health checks

Code: BR-005 Name: Every Service registers in the Service Registry and exposes a health check Description: A service instance registers on startup and exposes a health/readiness endpoint. Unhealthy instances are removed from routing. Service discovery relies on the registry to route traffic only to healthy instances. Motivation: Enable dynamic scaling and reliable routing without static configuration. Priority: HIGH Actors: Service Mesh, Service Owner Traceability: glossary "Service Discovery", "Service Registry", "Service-Level Objective (SLO)"; events/domain-events.md event HealthCheckFailed.

---

BR-006 - Contract versioning without breakage

Code: BR-006 Name: A ServiceContract evolves backward-compatibly or introduces a new version Description: Changes to an API or event schema must not break existing consumers. Additive changes are allowed; breaking changes require a new contract version and a coexistence period. Consumer-driven contract tests verify compatibility. Motivation: Allow independent deploys without coordinating the release of all consumers. Priority: HIGH Actors: Service Owner, API Consumer Traceability: glossary "Consumer-Driven Contract", "Ubiquitous Language"; BC-02.

---

BR-007 - Distributed tracing on every request

Code: BR-007 Name: Every cross-service request propagates a trace context Description: Every request or message propagates a trace identifier (trace-id, span-id) across service boundaries, so that an end-to-end operation can be reconstructed for debugging and observability. Motivation: Make a flow that crosses many services debuggable. Priority: MEDIUM Actors: Service Mesh, Service Owner Traceability: glossary "Distributed Tracing", "Observability".

---

BR-008 - Service boundaries aligned to Bounded Contexts

Code: BR-008 Name: A Service boundary derives from a domain Bounded Context Description: Service decomposition follows domain boundaries (DDD), not technical layers. Each service encapsulates a bounded context with its own ubiquitous language, avoiding anaemic or overly fine-grained services (nano-services). Motivation: Maximise cohesion and minimise inter-service chattiness. Priority: HIGH Actors: Service Owner Traceability: glossary "Domain-Driven Design (DDD)", "Bounded Context", "Modular Monolith", "Strangler Fig Pattern"; BC-01.