TorbatYar/docs/architecture/adr/ADR-012.md

ADR-012: Independent Enterprise Communication Platform

Field	Value
Status	Accepted
Date	2026-07-24
Deciders	Platform Architecture
Supersedes	—
Superseded by	—

Context

Business modules (CRM, Loyalty, Restaurant, etc.) need SMS and future channels. Putting providers inside each module would duplicate credentials, break failover consistency, and couple tenants to modules they may not subscribe to.

Core already sends auth OTP via Payamak — that auth path stays separate for now, but platform messaging must be a shared infrastructure service.

Decision

1. Introduce communication-service with sole ownership of communication_db (port 8005).
2. All outbound messaging (SMS first; email/push/social/voice later) goes through this service’s APIs and events.
3. Provider adapters live only inside Communication.
4. Dynamic contact sources resolve contacts via remote APIs — never copy business-module rows.
5. Tenants may activate Communication independently of other business modules.
6. Failures are tracked asynchronously; they must not abort calling business transactions.

Consequences

Positive

• Single provider registry, failover, templates, OTP, audit, and monitoring
• Clear module boundary for CRM CommunicationProvider contract fulfillment
• Extensible channel model without rewriting consumers

Negative

• Additional deployable service and database
• Eventual consistency for delivery status

Neutral

• Core auth OTP may later hand off to Communication when explicitly migrated

Alternatives Considered

1. Expand sms_panel / notification scaffolds separately — rejected; unified Communication owns multi-channel routing.
2. Keep providers in each business module — rejected; violates independence and DRY.

Related Documents

• communication-phase-8.md
• Module Registry
• ADR-001
• Module Boundaries