Deconstructing monolith software bounded contexts for domain driven design

Question

I'm starting to dive into domain driven design for a new project.

The software solution will be used by several departments to assign tasks to their employees.

The task assignment process is mostly similar for these departments. One of the differences is that some departments assign tasks to their employees only, others need employees from the other departments.

Now for the DDD, should I consider each department as a separate bounded context, or divide it according to features (ie. task assignment, users pool, reports, ...)

And one final question, how to handle code duplication in separate contexts?

Answer 1

You should analyze all the differences in behavior from the departments in order to make the correct architectural decision. The simplest case is the one in which you make only a single product (a single bounded context, i.e. TaskManagement) that is used by all departments.

From what I understand so far, the differences are only related to the authorization: some departments may assign tasks only to some users, other departments may assign tasks to all users and so on. This can be extracted in a separate module that corresponds to a separate bounded context: Authorization. This means that the TaskManagement bounded context is not affected by these differences, a task has the same behavior for all departments.

The Authorization is largely debated on books/the internet, but as a little implementation suggestion, you could make the calls to the Authorization bounded context in the Application layer, before the calls to the Aggregates from the TaskManagement bounded context; the UI also uses the Authorization bounded context, in order to load the corresponding user list when a task is assigned.

TaskManagement is a bounded context that can permit off-the-shelf solutions. For example, Jira is used by a lot of companies and by all departments from those companies. In the "worst" case scenario, you can have different instances of the TaskManagement application for each department, with a different database, but with the same source code.

Answer 2

I'm starting to dive into domain driven design for a new project.

The software solution will be used by several departments to assign tasks to their employees.

The task assignment process is mostly similar for these departments. One of the differences is that some departments assign tasks to their employees only, others need employees from the other departments.

I can identify two reasons this difference might be significant:

1. A department needs to enforce a business rule that will prevent it from assigning tasks to any employee that isn't its own. If not, who cares?

2. One department mostly assigns tasks to its own while another mostly assigns tasks to others. This creates a UI issue because the most likely employees should be the easiest to find.

Now for the DDD, should I consider each department as a separate bounded context, or divide it according to features (ie. task assignment, users pool, reports, ...)

Reasons to group by department:

1. Responsible to only one source of change.
2. Domain expert need only provide ubiquitous language for a domain limited to their expertise.
3. Inter-domain communication can be modeled on inter-department communication.
4. Grouping by department allows you to leverage knowledge of the individual business

Reasons not to group by department:

1. As the company grows the departments responsibilities can creap
2. Departments responsibilities can overlap
3. Grouping by department requires you to leverage knowledge of the individual business rather than remain generic.

And one final question, how to handle code duplication in separate contexts?

Don't over do DRY. Don't Repeat Yourself was never intended to force you to scour the code base for every loop and math expression that might look like what you're about to write. Duplication that allows similar responsibilities in different places to react to change by varying independently is a good thing. It's only when a design decision is being spread to multiple places, places that will all have to change together when that decision changes, that I will start beating you with the DRY stick. This is about making decisions in one place. It's not about how the code looks.