Employee Profile and Contact Storage

Summary

Employee Service has persisted structures for personal profile values and six profile child collections. Some application methods support full profile replacement, but the reviewed public API exposes only document-reference addition among these profile mutations; broader API availability is Not implemented or Requires confirmation.

Audience

• Backend developers and QA engineers
• Security engineers and solution architects

Confirmed service-owned storage

Concept	Storage form	Tenant behavior	Source
Basic contact	Employee root scalar values	Root query filter	Domain/Employees/Employee.cs
Address and government identifiers	Employee root scalar values	Root query filter	same
Employment and birth date	Owned value stored with Employee root	Root query filter	same
Emergency contacts	Child collection	Stamped tenant ID and child query filter	same
Education	Child collection	Stamped tenant ID and child query filter	same
Experience	Child collection	Stamped tenant ID and child query filter	same
Skills	Child collection	Stamped tenant ID and child query filter	same
Bank details	Child collection	Stamped tenant ID and child query filter	same
Document references	Child collection containing metadata, not file bytes	Stamped tenant ID and child query filter	same

Persistence behavior

Profile update methods replace complete supplied child collections rather than patching individual children. EF relationships cascade physical root deletion to these rows. Child objects receive Employee and tenant identifiers from the aggregate before persistence.

Document-reference storage contains descriptive and storage-reference metadata. The Employee Service migration does not store document content. Document lifecycle and binary ownership outside this reference are separate bounded-context concerns.

Transitional legacy comparison

The monolith Labor model stores some contact, compensation, attendance, bank, and employee values directly, and its EmployeeDocument model is separate. Those Legacy structures are not Employee Service tables. Compatibility DTO fields may be defaulted or ignored even when a similarly named Employee Service property exists; API behavior must be verified independently from storage capability.

Public-safety constraints

No personal records, account values, government identifiers, storage locations, or file references are reproduced here. Access-control and encryption-at-rest assurances were not established by the reviewed model and are Requires confirmation at the deployment boundary.

Source References

• microservices/src/employee-service/Domain/Employees/Employee.cs
• microservices/src/employee-service/Infrastructure/EmployeeDbContext.cs
• microservices/src/employee-service/Application/Employees/Employees.cs
• Models/Labor.cs
• Models/EmployeeDocument.cs
• Data/AppDbContext.cs

Related Articles

• Employee profile
• Employee aggregate storage
• Security boundaries

See Also

• Employee document-reference API
• Tenant isolation

Keywords

• Profile persistence
• Employee contacts
• Sensitive data concepts

Revision Information

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