4

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?

  • Martin Fowler says that the division is typically by department. He goes on to say that each domain has its own ubiquitous language. "Different groups of people will use subtly different vocabularies in different parts of a large organization." – Robert Harvey Aug 22 '18 at 18:36
  • You handle code duplication in separate contexts the same way you handle code duplication anywhere else. – Robert Harvey Aug 22 '18 at 18:37
  • So to handle a specific action (say "getDepartmentEmployees") I should have a single function used by multiple contexts, but wouldn't that contradict the use of separate contexts and make it harder to use a separate ubiquitous language for each one (one department might call them employees and the other might call them technicians). – Muhmmad Aziz Aug 22 '18 at 19:04
  • I just read "All communication between bounded contexts go via pre-defined interfaces like queries and commands if you do CQRS" in this post. is that the right way to avoid duplications? – Muhmmad Aziz Aug 22 '18 at 19:13
  • Why are you insisting that every method go through a defined interface between bounded contexts? That's not how real-world software works. If you want to use the Math library in C# or Java, you don't create an interface between contexts to do that, nor do you duplicate the Math library code in both contexts. – Robert Harvey Aug 22 '18 at 19:17
4

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.

4

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.

  • 1
    "This is about making decisions in one place. It's not about how the code looks." So much this. I've seen so many people develop behemots hyper-abstracted of code with so many layers that would make danish pastry jealous just because "this is how code is supposed to look". – T. Sar Aug 23 '18 at 11:31

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.