Employee Aggregate Storage

Summary

The Employee root uses a GUID primary identifier and integer tenant identifier. Employment is an EF-owned value stored with the root. Profile collections, notes, document references, and timeline entries are separate child objects linked to the root by required foreign keys.

Audience

• Backend developers and QA engineers
• Solution architects reviewing aggregate boundaries

Aggregate model

The dashed-in-concept organization and manager relationships are stored as nullable GUID references but are not configured as EF foreign keys. Application validators establish existence, activity, department/designation compatibility, and self-manager rules where the reviewed command path uses them.

Root storage

Concept	Confirmed storage behavior	Source
Identity	GUID root identifier plus tenant identifier	Domain/Employees/Employee.cs
Employee code	Normalized value; database uniqueness scoped by tenant	EmployeeDbContext.cs
Name/contact	Root scalar values with configured length limits	same
Status	Enum persisted as a bounded string; termination controls active state	same
Employment	Type, work location, joining, confirmation, and birth dates stored inline	same
Organization	Nullable department, designation, and manager GUID references	same
Personal profile	Address and government-identifier concepts stored on the root	same
Lifecycle timestamps	Creation and update timestamps on the root	Domain/Employees/Employee.cs

Child storage

All eight child types have their own GUID identifier, Employee identifier, and tenant identifier. EF configures a required Employee foreign key with cascade delete for education, experience, emergency contacts, skills, bank accounts, document references, notes, and timeline entries. Aggregate replacement methods stamp Employee and tenant identity onto new children.

Lifecycle implications

The implemented Employee deletion method is a soft-delete/termination transition. No current direct Employee delete endpoint was documented in Epic 5.3. Physical deletion behavior is nevertheless configured at the database relationship level: if a root row is physically removed by an approved future path, its child rows cascade. Such a physical deletion workflow is Not implemented in the reviewed public API.

Source References

• microservices/src/employee-service/Domain/Employees/Employee.cs
• microservices/src/employee-service/Domain/Common/ValueObjects.cs
• microservices/src/employee-service/Infrastructure/EmployeeDbContext.cs
• microservices/src/employee-service/Infrastructure/Migrations/20260701173627_InitialEmployeeSchema.cs
• microservices/src/employee-service/Infrastructure/Migrations/EmployeeDbContextModelSnapshot.cs

Related Articles

• Employee domain model
• Employee profile
• Profile and contact storage

See Also

• Organization storage
• Data integrity and transactions

Keywords

• Aggregate root
• Owned employment value
• Employee child storage

Revision Information

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