I am currently trying out DDD with a sample application, "Task Management System". This is not related to any specific domain as such, it will be a generic application which can be used in any domain.
- Main concept of Task management is "Task". It can contain multiple sub-tasks. Every task will be created with some predefined properties setup by user
- Task can have duration, and can be assigned to different role(s) or user(s)
- Each sub-task can be assigned to different role(s) or user(s)
- Task can be sent for approval for other user(s) or role(s)
- After approval, task & sub-tasks will be available for execution
Based on above knowledge, I have thought of having three bounded contexts.
a) Task & Sub Tasks - Core Domain
b) Approval Process - Supporting Domain
c) Roles, Users, Authorization - User Domain
Roles, Users in generic domain, will have a different meaning in Task domain. Example: A user in User domain will be called as creator/approver/Assignee in task domain. Similarly, roles in User domain will be called as Assignee/Approver Role.
Data related to list of users, roles will be given by an external system and authentication will be also done by external system. List of users and roles will be used for task creation, assignment and approval.
Need some clarity on following points
- Have I clearly identified bounded contexts ?
- Am I right in separating the users, roles in different context even though they are very important for task creation ?
- Should be the approval process be in different context ? I am confused on this part because this is actually very important and part of task management.