0

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 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 be 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, Authorisation - 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.
  • Since the approval part „is very important“ I’m not sure if I completely understand it. Do you mean: the properties are checked by another user and the task is approved (in some sense of allowed) to be started? – Hartmut Braun Dec 23 '19 at 8:30
0

Domain Driven Design is a software development methodology to solve complex and evolving business problems. One of the main intention of domain driven design is bridge the gap between the business and developers. Domain Driven Design has two parts -The strategic design and tactical design.

Strategic design is about breaking down the complexities in to domains and sub domains. The domains are sub domains have to be aligned with the businesses. One possibility is one department maps to the core domain and the other department maps to other sub domain. You might take a look at Conway's law. This is one of the most important part of DDD. This ensures that every domain has it's own ubiquitous language. The intention of the domains are clearly known to business and developers.

Tactical design is about making the code more readable. It has couple of tools such as aggregates, aggregate root, port and adapter architecture, etc...

To answer you question if you have identified the bounded contexts clearly. Each bounded context would correspond to a domain (especially in a green field project). Bounded context is in the solution space. Sub domain and core domain are in the problem space. Identification of bounded context is not an individual activity. It has to be done in sync with the business. So ideally, you should go back to the business and identify the domains and map the bounded contexts to it.

From your current scenario,

  1. Task & Sub Tasks - Core Domain
  2. Approval Process - Supporting Domain
  3. Roles,Users, Authorization - User Domain

The approval process is quite closely associated with the task and sub tasks. It appears to me that they will be describable by the same ubiquitous language. There may be technical complexities in the approval process but it looks quite close to the task and sub tasks domain.

Roles, Users and Authorization: Roles and Users are looks like another another domain. It could be used in other parts of the application. The authorization part looks like it should be in the core domain. May be while authorizing, we may need to get the roles and user information from the other domain.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.