Stage 7 · Master
Introduction to the Meridian Platform
The Domain Model
The HOA management domain, its core entities, and how responsibility for each is split across the platform's four services.
Domain Overview
Meridian manages homeowners association (HOA) operations for multiple independent associations, each represented as a tenant. Within a tenant, users hold memberships with a role (owner, board member, resident), residents are linked to units within buildings, and each tenant tracks announcements, complaints, invoices, and payments.
Entity Ownership by Service
| Service | Owns | Responsibility |
|---|---|---|
| identity-service | Tenants, users, memberships, roles, permissions | Authentication, tenant resolution, and RBAC. |
| community-service | Residents, units, buildings, announcements, complaints | Non-financial HOA operations and resident-facing content. |
| billing-service | Invoices, payments | Dues invoicing and payment processing, scoped per resident and unit within a tenant. |
| reporting-service (planned) | None directly | Read-only aggregation across the other three services, consumed via Kafka events once they hold real data. |
Why This Domain
The domain is chosen for its structural properties, not its business interest. It forces multi-tenant isolation (each HOA is a separate tenant), a clear service-ownership boundary (financial data in billing-service is kept isolated from community data), and a realistic reason for asynchronous processing (payment webhooks, notification delivery) without requiring domain-specific business logic that would distract from the platform architecture itself.
Out-of-Scope Entities
- Vendor and contractor management
- HOA board election and voting workflows
- Document storage beyond complaint attachments and billing receipts
- Third-party payment processor integration detail (Stripe, etc. — treated as an external dependency, not implemented in this course)
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.