Skip to main content

Employee Repository Pattern

Summary

Repository interfaces are declared with the domain and implemented by Infrastructure. They support aggregate loading, uniqueness/existence checks, writes, and query composition.

Audience

  • Backend developers
  • QA engineers and solution architects

Reference Content

Repository ports

  • IEmployeeRepository: load Employee with or without complete profile collections, test code/email uniqueness, add an aggregate, and expose a tenant-filtered query.
  • IDepartmentRepository: load, test code uniqueness, test active employee assignment, add, and query departments.
  • IDesignationRepository: load, test code uniqueness, add, and query designations.
  • ITimelineRepository: read an employee timeline or a bounded tenant feed.

Implementations

Concrete repositories share the scoped Employee persistence context. Full-profile loading explicitly includes employee-owned child collections. Timeline reads are no-tracking and newest-first. Uniqueness checks deliberately inspect the tenant's complete set, including inactive records, while normal queries inherit tenant filtering.

Query exposure

The domain ports expose IQueryable for application-side projection and filtering. This supports efficient read paths but couples the port surface to LINQ and permits query construction outside Infrastructure. Whether to replace query exposure with dedicated read ports Requires confirmation.

Unit of work

Repositories do not commit independently. Application handlers commit through IUnitOfWork, allowing aggregate, audit, and outbox changes to be saved together.

Source References

  • microservices/src/employee-service/Domain/Repositories.cs
  • microservices/src/employee-service/Infrastructure/Persistence.cs
  • microservices/src/employee-service/Application/Common/Abstractions.cs

See Also

Keywords

  • Persistence port
  • Aggregate repository
  • Unit of work

Revision Information

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