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.csmicroservices/src/employee-service/Infrastructure/Persistence.csmicroservices/src/employee-service/Application/Common/Abstractions.cs
Related Articles
See Also
Keywords
- Persistence port
- Aggregate repository
- Unit of work
Revision Information
- Status: Draft
- Last reviewed: 2026-07-15
- Review cycle: Quarterly