Employee Data Integrity and Transactions
Summary
Integrity is split across domain invariants, application validation, EF relationships, database uniqueness, and one context commit. Not every logical reference is protected by a database foreign key, and no optimistic-concurrency token was found.
Audience
- Backend developers and QA engineers
- Solution architects reviewing consistency boundaries
Integrity layers
| Layer | Confirmed responsibility | Source |
|---|---|---|
| Domain | Required/normalized identity values, self-manager rejection, status transitions, document/note invariants, soft deletion | Domain/Employees/Employee.cs |
| Application validators | Tenant, duplicate code/email, active references, designation/department match | Application/Validators/EmployeeCommandValidators.cs |
| Organization services | Tenant-scoped code checks, active-employee department restriction, deactivation | Application/Organization/Organization.cs |
| EF model | Required root/child relationship and cascade behavior | Infrastructure/EmployeeDbContext.cs |
| Database | Primary keys and verified unique indexes | migrations and snapshot |
Important relationships
The eight Employee child collections have database foreign keys to Employee and cascade on physical root deletion. Employment is owned inline. Department, designation, manager, department parent/head, and designation department are stored as logical references without configured database foreign keys. They rely on domain/application checks, so bypassing the application layer can create inconsistent references.
Transaction participants
| Participant | Added/changed before commit | Same context save | Source |
|---|---|---|---|
| Employee/organization aggregate | Yes | Yes | command handlers/services |
| Timeline children | By aggregate methods | Yes | Domain/Employees/Employee.cs |
| Technical audit | By audit writer | Yes | Infrastructure/Persistence.cs |
| Supported outbox records | By context override before save | Yes | Infrastructure/EmployeeDbContext.cs |
EF Core applies its normal transactional SaveChanges behavior for a multi-statement commit. The UnitOfWork adds no explicit distributed transaction. Broker publication is outside the local transaction. Compatibility Employee update can invoke several commands with separate saves, so all-or-nothing behavior across the combined compatibility request is Not implemented.
Uniqueness and concurrency
- Database uniqueness: Employee code, Department code, and Designation code within a tenant; outbox event identity globally within that object.
- Application-only uniqueness: Employee email within a tenant.
- No row version, timestamp concurrency token, explicit concurrency configuration, or conflict retry was found. Optimistic concurrency protection is Not implemented.
Delete behavior
Employee domain deletion is a status/active-state transition. Department and Designation deletes deactivate records. Department deactivation checks active assignments; Designation deactivation does not. Physical Employee deletion would cascade to child collections, but no reviewed public route performs it. Audit and outbox objects are not Employee children and have no cascade relationship.
Source References
microservices/src/employee-service/Domain/Employees/Employee.csmicroservices/src/employee-service/Domain/Organization/Organization.csmicroservices/src/employee-service/Application/Validators/EmployeeCommandValidators.csmicroservices/src/employee-service/Application/Organization/Organization.csmicroservices/src/employee-service/Infrastructure/EmployeeDbContext.csmicroservices/src/employee-service/Infrastructure/Persistence.csmicroservices/src/employee-service/Infrastructure/Migrations/EmployeeDbContextModelSnapshot.cs
Related Articles
See Also
Keywords
- Unit of work
- Referential validation
- Concurrency limitation
Revision Information
- Status: Draft
- Last reviewed: 2026-07-15
- Review cycle: Quarterly