Skip to main content

Organization Data and Tenancy

Summary​

Platform owns tenant/company control-plane data. Employee Service owns workforce organization and employee master data in its PostgreSQL schema. The monolith retains overlapping compatibility data during cutover.

Audience​

  • Platform administrators and implementation partners
  • Developers, DevOps engineers, architects, and security engineers

Purpose​

This ownership model supports tenant isolation and prevents similarly named Company, Department, Designation, User, and Employee records from being treated as one shared aggregate.

Architecture​

Business concepts​

  • Platform ownership — Implemented: Company, Company Setting, branding, tenant audit, and related control-plane records belong to Platform.
  • Employee ownership — Implemented: Department, Designation, Employee organization references, audit, timeline, and outbox records belong to Employee Service.
  • PostgreSQL service schema — Implemented: Employee Service configures a service-owned schema and persistence context.
  • Tenant scoping — Implemented: global query filters scope employees, organization masters, audits, and employee child entities by tenant, with a controlled platform-wide context.
  • Conceptual relationships — Implemented: employees reference department, designation, and reporting manager; designations may reference departments; departments may reference parent/head.
  • Auditing and timeline — Implemented: organization commands write audit records; employee changes also write timeline/domain events.
  • Monolith ownership — Transitional: legacy numeric identifiers and overlapping organization/user/labor records remain behind Gateway-controlled cutover.
  • Cross-store synchronization — Requires confirmation: no complete bidirectional synchronization was confirmed.

Technical implementation​

Employee Service enforces tenant-specific uniqueness for employee, department, and designation codes and applies tenant filters at persistence-query level. Compatibility contracts bridge identifier and response-shape differences without creating fictional legacy IDs. Individual database tables, indexes, configuration names, and connection details are intentionally excluded.

Source References​

  • microservices/src/employee-service/Infrastructure/EmployeeDbContext.cs
  • microservices/src/employee-service/Infrastructure/Persistence.cs
  • microservices/src/employee-service/Domain/Organization/Organization.cs
  • microservices/src/employee-service/Domain/Employees/Employee.cs
  • microservices/src/employee-service/docs/employee-compatibility-placeholders.md
  • microservices/src/platform-service/Data/PlatformDbContext.cs
  • microservices/src/platform-service/Domain/Entities/Company.cs
  • microservices/src/platform-service/Domain/Entities/CompanySetting.cs
  • microservices/src/gateway-api/Program.cs
  • Models/Department.cs
  • Models/Designation.cs
  • Models/Labor.cs

See Also​

Keywords​

  • Data ownership
  • Tenant isolation
  • Employee bounded context

Revision Information​

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