Attendance Database Ownership and Boundaries

Summary

Attendance Service owns Attendance and Time Office persistence. Other domains are represented only by identifiers, local projections, integration calls, or snapshots.

Audience

• Backend developers, architects, QA engineers, and data-governance reviewers

Ownership model

Data category	Owner / classification	Boundary
Attendance records, punches, reopen requests	Attendance Service / master	Aggregate state stored locally
Shifts, weekly offs, policies, assignments	Attendance Service / Time Office master	Current ownership; legacy coexistence remains Transitional
Employee profile	Employee domain master; Attendance-local read model	No cross-database join is modeled
Leave	External domain	No Leave table is modeled in this context
Payroll-approved snapshot	Attendance-owned snapshot; Payroll is a consumer	Snapshot is not the Payroll master record
Audit, timeline, outbox	Attendance Service / operational history	Stored with Attendance changes
Legacy persistence	Monolith / Transitional	Read-only source for backfill; no shared-table assumption

Automatic synchronization of the employee projection from integration events is Foundation / Requires confirmation at runtime; the current source explicitly supports an upsert path.

Source References

• microservices/src/attendance-service/Infrastructure/AttendanceDbContext.cs
• microservices/src/attendance-service/Domain/Attendance/EmployeeProfile.cs
• microservices/src/attendance-service/Domain/Attendance/PayrollApprovedSnapshot.cs
• microservices/src/attendance-service/Backfill/AttendanceMonolithSourceReader.cs

Related Articles

• Attendance database
• Attendance technical documentation
• Attendance API documentation

See Also

• Attendance business documentation
• Attendance overview

Keywords

• Attendance persistence
• EF Core
• PostgreSQL

Revision Information

• Status: Draft
• Last reviewed: 2026-07-15
• Review cycle: Quarterly