Recruitment Repositories and Persistence

Summary

Repository interfaces expose aggregate-specific reads, detail loading, public lookups, queries, and adds; EF implementations share one scoped DbContext and unit of work.

Audience

Backend and frontend engineers, architects, QA, support, security reviewers, and operators responsible for Recruitment.

Overview

Six aggregate repositories are registered. Detail methods explicitly include child collections where needed. Query methods expose IQueryable for application-side composition. Compatibility lookups resolve numeric identities to native aggregate identities.

The DbContext applies tenant global filters to Recruitment-owned records, maps child relationships, indexes common tenant/status and identity lookups, and stores audit, timeline, processed-event, and outbox evidence. UnitOfWork delegates to the DbContext save override, which maps queued domain events to outbox messages in the same database transaction.

There is no generic repository, specification framework, second-level cache, or separate read database.

Requires confirmation

Production ownership, authorization policy, operational thresholds, and future design decisions require confirmation.

Source References

• microservices/src/recruitment-service/Domain/Repositories.cs
• microservices/src/recruitment-service/Infrastructure/Persistence.cs
• microservices/src/recruitment-service/Infrastructure/RecruitmentDbContext.cs

Related Articles

• Recruitment technical documentation
• Recruitment business documentation
• Recruitment known limitations

See Also

• Recruitment module
• Recruitment API foundation

Keywords

• Recruitment technical architecture
• Recruitment Service
• Repositories and Persistence

Revision Information

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