Recruitment Candidate Model

Summary

Candidate owns application links, stage history, notes, and document references while exposing stage and compensation-approval state.

Audience

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

Overview

Aggregate factories require a name and at least one contact method. Stage changes append history and may no-op when unchanged. Notes require content. Document-reference creation validates metadata but content storage occurs through an application gateway.

Same-opening duplicate detection is repository/application behavior, not a database uniqueness constraint or aggregate invariant. General stage mutation permits any defined stage. Global deduplication, candidate merge, assigned recruiter, deletion, archival, retention, and subject-access workflows are not implemented.

Requires confirmation

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

Source References

• microservices/src/recruitment-service/Domain/Recruitment/Candidate.cs
• microservices/src/recruitment-service/Application/Commands/CandidateCommands.cs
• microservices/src/recruitment-service/Infrastructure/Persistence.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
• Candidate Model

Revision Information

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