Employee Data Ownership and Boundaries
Summary
Employee Service owns workforce master persistence for its extracted bounded context. Platform separately owns tenant and company control-plane data. The monolith retains Legacy workforce tables during transition, while downstream services own their own read models.
Audience
- Solution architects and backend developers
- DevOps engineers planning data boundaries
Ownership model
Confirmed boundaries
| Owner | Owns | Does not imply | Source |
|---|---|---|---|
| Employee Service | Employee aggregate, departments, designations, profile children, timeline, audit, outbox | Ownership of company/control-plane data | microservices/src/employee-service/Infrastructure/EmployeeDbContext.cs |
| Platform Service | Tenant, company, and control-plane persistence | Direct table sharing with Employee Service | microservices/src/platform-service/Data/PlatformDbContext.cs |
| Monolith | Legacy Labor and organization persistence | Canonical ownership after final cutover | Data/AppDbContext.cs |
| Downstream services | Their service-specific Employee projections/read models | Write ownership of Employee master data | microservices/src/payroll-service/Infrastructure/PayrollDbContext.cs, microservices/src/leave-service/Infrastructure/LeaveDbContext.cs |
Aggregate and organization ownership
Employee, its owned employment value, and eight child collections share one aggregate persistence boundary. Department and Designation are separate aggregates inside the same Employee Service schema. Employee assignment fields reference those objects logically; the reviewed EF model does not configure cross-aggregate database foreign keys.
No shared-table assumption
Project references, separate contexts, and separate migrations establish independent persistence models. Integration or compatibility behavior must not be implemented by directly updating another service's tables. Any approved data replication should use an explicit integration or migration mechanism.
Transitional concerns
- Final monolith-to-service system-of-record cutover is Requires confirmation.
- Historical backfill and reconciliation ownership are Not implemented in Employee Service.
- Downstream delivery and read-model freshness are covered by future event documentation, not by the existence of source tables alone.
Source References
microservices/src/employee-service/Infrastructure/EmployeeDbContext.csmicroservices/src/platform-service/Data/PlatformDbContext.csmicroservices/src/payroll-service/Infrastructure/PayrollDbContext.csmicroservices/src/leave-service/Infrastructure/LeaveDbContext.csData/AppDbContext.cs
Related Articles
See Also
- Compatibility and backfill
- Future Employee integration-contract documentation (Not implemented)
Keywords
- Data ownership
- Bounded context
- No shared tables
Revision Information
- Status: Draft
- Last reviewed: 2026-07-15
- Review cycle: Quarterly