Domain-Driven Design: Tackling Complexity in the Heart of Software

Example
Employee Payroll and Pension, Part 1
The HR department of a medium-sized company has a simple program for calculating payroll and
pension contributions.

---

Figure 16.15. The old model, overconstrained for new requirements
Figure 16.16. Some employees represented using the old model
But now, the management has decided that the office administrators should go into the "defined
benefit" retirement plan. The trouble is that office administrators are paid hourly, and this model
does not allow mixing. The model will have to change.
The next model proposal is quite simple: just remove the constraints.

---

Figure 16.17. The proposed model, now underconstrained
Figure 16.18. Employees can be associated with the wrong plan.
This model allows each employee to be associated with either kind of retirement plan, so each
office administrator can be switched. This model is rejected by management because it does not
reflect company policy. Some administrators could be switched and others not. Or the janitor could
be switched. Management wants a model that enforces the policy:
Office administrators are hourly employees with defined-benefit retirement plans.
This policy suggests that the "job title" field now represents an important domain concept.
Developers could refactor to make that concept explicit as an "
Employee Type
."
Figure 16.19. The Type object allows requirements to be met.

---

Figure 16.20. Each Employee Type is assigned a Retirement Plan.
The requirements can be stated in the 
UBIQUITOUS LANGUAGE
as follows:
An 
Employee Type
is assigned to either