Skip to main content

Persistence Architecture

Audience​

Developers, database engineers, QA engineers, support engineers, security engineers, solution architects, and implementation partners.

Reference Content​

This page records source-verified Workforce Scheduling persistence behavior and boundaries.

Summary​

Application services depend on repository and unit-of-work ports. EF Core adapters use one scoped Attendance context. Query repositories expose both purpose-built methods and queryables. Audit and timeline writers add evidence records to the same context.

Data flow​

Commands construct or update aggregates, add audit/timeline entries, and invoke the unit of work. Queries compose provider-side filters and projections. The context adds mapped attendance domain events to a transactional outbox during save, but scheduling aggregates have no mapped integration events.

Boundaries​

The backfill context derives from the canonical context and changes only compatibility-identity generation. The monolith source reader is separate from EF and performs read-oriented extraction; no operational details are reproduced here.

Coupling​

All Attendance layers share one project, so project boundaries do not enforce persistence direction. Returning queryables also exposes provider composition to application queries.

Source References​

  • microservices/src/attendance-service/Domain/Repositories.cs
  • microservices/src/attendance-service/Infrastructure/Persistence.cs
  • microservices/src/attendance-service/Infrastructure/AttendanceDbContext.cs
  • microservices/src/attendance-service/Backfill/ShiftPolicyBackfillTypes.cs

See Also​

Keywords​

  • Workforce Scheduling database
  • Shift persistence
  • Attendance policy storage

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-20
  • Next review: 2026-10-20