DDD Boundaries

Status: Federated from product architecture
Last updated: 2026-07-05

---

Authority documents

Product	Document
PRD-001 (Dental Clinic ROS)	PRD-001 module boundaries — 534 lines, all platform + product modules
PRD-000 (Experience Platform)	PRD-000 module boundaries
Registry	Registry dependency graph

---

Core rules (all products)

1. No business logic in Controllers, Filament Resources, Form Requests, or Blade views
2. Writes through Application Actions or Services only
3. No cross-module Infrastructure imports — use contracts, events, Shared kernel
4. DTO-first at module boundaries — never expose Eloquent models
5. Clinic scoping — all clinic-owned data via ClinicAwareInterface (PRD-001)

---

Layer model

Domain/          → Entities, ValueObjects, Events, Enums (no framework)
Application/     → Actions, Services, DTOs, Queries, Contracts
Infrastructure/  → Models, Repositories, External integrations
Http/            → Controllers, Requests (thin)
Providers/       → Module registration

---

Context map (PRD-001 summary)

Bounded context	Communicates via
Leads → CRM	Events, public application services
AI → CRM/Leads	Tool handlers + contracts only
Marketing → Leads	Events
Compliance → all content modules	Review workflows, events
Saas → all tenant modules	EntitlementContract, tenancy middleware

Full map: business-capability-map.md

---

Related

• Module architecture
• Architecture principles
• Architecture tests

Breadcrumbs: Home → Architecture → DDD Boundaries