Dividing an HR Application into Bounded Contexts: Understanding How to Split a Domain into Multiple Models

I’m trying to understand bounded contexts by trying to apply them to an example HR application. According to a book called Patterns, Principles, and Practices of Domain-Driven Design (PPPDDD), context boundaries can be influenced by: Ambiguity in terminology and concepts of the domain Alignment to subdomains and business capabilities Team organization and physical location Legacy code base Third‑party integration My goal is to see how each of these factors might apply in a realistic HR system. Thoughts After Analysis Each feature varies in complexity but I do not see clear boundaries. The legacy app would be in another context but that's all I could think of. More details after the next section. HR Application Details 1. Employee Information A page that displays employee details Allow edits (which HR must approve) Show a table detailing estimated salary for the current month (full payroll processing is not in scope) 2. Attendance & Leaves Leave Types: annual, sick, emergency Leave balance is limited by predefined allotments per type Annual Leave Planning: Planned at year-end for the next year Departmental capacity limits (e.g., only X% of staff can be on leave at once, as defined in company policy, which may change) Leave balance of 30 days which can be spread over the year and can take maximum 15 days at a time Attendance Tracking: Office time must be pulled from a database that is populated by an attendance machine. Displays overtime, late minutes, out-of-office hours (tracked via check-ins and check-outs from the attendance machine), etc. Business rules (e.g., max out‑of‑office hours per day; must be recouped over five working days) Ability to convert out-of-office time into a leave request. Legacy App: existing application that supports entering sick/emergency leaves only; does not support annual leave planning 3.Performance Evaluation Structured form filled by an employee's supervisor(s) Hierarchical review and acknowledgement workflow: Supervisor completes and submits the evaluation Reviewed and acknowledged up the reporting hierarchy Employee views read‑only and acknowledges the final version 4. Asset Declaration Annual form where employees declare their income, assets and liabilities Employees can create, view, edit, and resubmit their declarations each year My analysis of the factors mentioned at the beginning of this post 1. Ambiguity in Terminology and Concepts Terms seem consistent across features. I noticed different features only reference the subset of Employee properties they need (e.g., performance evaluation uses name and supervisor list; asset declaration uses only name and ID) but there are no properties that mean different things in different places. 2. Alignment to Subdomains & Business Capabilities I could think of only one "business capability" which is HR. According to the book a business capability is a grouping of people in an organization that collaborate on business processes made up of lower-level capabilities. 3. Team Organization and Physical Location I don't understand this factor as I thought bounded contexts are all about ensuring consistency in ubiquitous language. I don't understand how software development team organization has anything to do with the domain. 4. Legacy Code Base The already existing application for taking sick and emergency leave could be a bounded context. 5. Third Party Integration There is none. Question Assuming the above information is all you have from HR, how would you divide this HR application into bounded contexts? Would DDD tactical patterns be helpful in any of the contexts?

Jun 14, 2025 - 03:00

I’m trying to understand bounded contexts by trying to apply them to an example HR application. According to a book called Patterns, Principles, and Practices of Domain-Driven Design (PPPDDD), context boundaries can be influenced by:

Ambiguity in terminology and concepts of the domain
Alignment to subdomains and business capabilities
Team organization and physical location
Legacy code base
Third‑party integration

My goal is to see how each of these factors might apply in a realistic HR system.

Thoughts After Analysis

Each feature varies in complexity but I do not see clear boundaries. The legacy app would be in another context but that's all I could think of. More details after the next section.

HR Application Details

1. Employee Information

A page that displays employee details
Allow edits (which HR must approve)
Show a table detailing estimated salary for the current month (full payroll processing is not in scope)

2. Attendance & Leaves

Leave Types: annual, sick, emergency
Leave balance is limited by predefined allotments per type
Annual Leave Planning:
- Planned at year-end for the next year
- Departmental capacity limits (e.g., only X% of staff can be on leave at once, as defined in company policy, which may change)
- Leave balance of 30 days which can be spread over the year and can take maximum 15 days at a time
Attendance Tracking:
- Office time must be pulled from a database that is populated by an attendance machine.
- Displays overtime, late minutes, out-of-office hours (tracked via check-ins and check-outs from the attendance machine), etc.
- Business rules (e.g., max out‑of‑office hours per day; must be recouped over five working days)
- Ability to convert out-of-office time into a leave request.
Legacy App: existing application that supports entering sick/emergency leaves only; does not support annual leave planning

3.Performance Evaluation

Structured form filled by an employee's supervisor(s)
Hierarchical review and acknowledgement workflow:
1. Supervisor completes and submits the evaluation
2. Reviewed and acknowledged up the reporting hierarchy
3. Employee views read‑only and acknowledges the final version

4. Asset Declaration

Annual form where employees declare their income, assets and liabilities
Employees can create, view, edit, and resubmit their declarations each year

My analysis of the factors mentioned at the beginning of this post

1. Ambiguity in Terminology and Concepts

Terms seem consistent across features. I noticed different features only reference the subset of Employee properties they need (e.g., performance evaluation uses name and supervisor list; asset declaration uses only name and ID) but there are no properties that mean different things in different places.

2. Alignment to Subdomains & Business Capabilities

I could think of only one "business capability" which is HR. According to the book a business capability is a grouping of people in an organization that collaborate on business processes made up of lower-level capabilities.

3. Team Organization and Physical Location

I don't understand this factor as I thought bounded contexts are all about ensuring consistency in ubiquitous language. I don't understand how software development team organization has anything to do with the domain.

4. Legacy Code Base

The already existing application for taking sick and emergency leave could be a bounded context.

5. Third Party Integration

There is none.

Question

Assuming the above information is all you have from HR, how would you divide this HR application into bounded contexts? Would DDD tactical patterns be helpful in any of the contexts?