Extending Domain Models
Relevant source files
The following files were used as context for generating this wiki page:
- Part1/API/src/main/java/com/example/api/model/Employee.java
- Part1/API/src/main/java/com/example/api/model/Department.java
- Part1/API/src/main/java/com/example/api/model/Assignment.java
- Part1/API/src/main/java/com/example/api/controller/EmployeeController.java
- Part1/API/src/main/java/com/example/api/controller/AssignmentController.java
- Part1/API/src/main/resources/api-spec.yaml
- Part1/API/src/main/java/com/example/api/entity/AppUser.java
Introduction
Extending domain models in the SafeDispatch HQ Administration API involves managing the relationships and attributes of core entities such as Employees and Departments through a centralized link entity. The primary objective is to allow complex associations where employees can be assigned to various departments with specific roles and access levels.
The system utilizes a relational data model managed via JPA (Jakarta Persistence API) to ensure data integrity and facilitate administrative operations like promotions, assignments, and department management.
Sources: api-spec.yaml:3-6, Assignment.java:1-10
Core Entities and Relationships
The domain model is built around three primary entities: Employee, Department, and Assignment. While Employee and Department hold static information, the Assignment entity acts as a junction that extends the domain by linking the two with contextual metadata.
Entity Relationship Structure
The following diagram illustrates how the Assignment entity connects employees to departments.
The diagram shows a one-to-many relationship from both Employee and Department to the Assignment entity, effectively creating a many-to-many relationship between the core models.
Sources: Employee.java:10-30, Department.java:10-25, Assignment.java:6-25
Domain Model Field Definitions
| Entity | Field | Type | Constraints | Description |
|---|---|---|---|---|
| Employee | email | String | @Email | Validated email address for the employee. |
contractType | String | @NotNull | Status such as "FULL_TIME". | |
salary | Integer | Base compensation. | ||
| Department | budget | Integer | @Positive | Financial allocation for the department. |
| Assignment | role | String | Specific job role within the assigned department. | |
accessLevel | String | Security or clearance level (e.g., "LEVEL_2"). |
Sources: Employee.java:18-35, Department.java:17-20, Assignment.java:21-22, api-spec.yaml:45-120
Extending Logic via Controllers
Domain models are not static; they are extended through business logic implemented in the controller and service layers. A key example is the promotion logic which modifies the Employee state based on temporal constraints.
Promotion Business Logic
The EmployeeController extends the basic CRUD functionality by providing a promotion endpoint. This logic validates the employee's start date before modifying the salary and role attributes.
The flow details the validation checks required before the domain model's state is updated.
Sources: EmployeeController.java:73-92, api-spec.yaml:230-250
Dynamic Domain Assignment
The Assignment entity allows the HQ administration to extend the domain by assigning employees to specific functional areas without altering the core Employee table structure.
Assignment Process
Assignments are created via a Data Transfer Object (DTO) in the AssignmentController. This process requires active IDs from both the Employee and Department repositories.
The sequence demonstrates how the system validates existing domain entities before creating a link between them.
Sources: AssignmentController.java:31-50, api-spec.yaml:290-315
Security User Model
The project also includes a specialized domain model for security, AppUser, which is distinct from the Employee model. This allows for administrative access control (HR vs. MANAGER) that is decoupled from the corporate employee directory.
- Username: Unique identifier for login.
- Password: BCrypt encoded string.
- Role: HR or MANAGER, determining access to restricted endpoints.
Sources: AppUser.java:10-25, api-spec.yaml:25-35
Summary
Extending domain models in this project is achieved through the use of an intermediary Assignment entity and specialized business logic in controllers. By separating core data (Employee/Department) from relational metadata (Role/AccessLevel) and security credentials (AppUser), the architecture maintains a flexible structure suitable for HQ administrative tasks.