Complex domain problem to be modeled with DDD

Question

There is a case management application.

New requirements want to add statuses to cases.

The case will go through a series of statuses until completion.

Each case belongs to a case type. There are many case types.

A case with a different case type might go through statuses in a different order. Each case type has its own status order. One status could be shared by two case types (status example: "Ongoing"), but the order is not necessarily the same.

Some statuses will be attended by another actor. Actor as in it could be a department, a manager level staff, or a division. Only the designated actor will be able to edit a particular status. For example, "Requested for documents from Dept2" status will be chosen by Dept1, after which Dept2 will add documents and then change the status to the next one. Some statuses are attended by a manager level staff.

It is a step by step process.

Upon change of each status, relevant staff will be emailed. For each status, the email recipient list could be different.

Upon change of each status, an email with a body specific to that status will be sent.

During some transitions from one status to the next, a new staff must be assigned to the case. Different statuses will be attended to by different assigned staff.

There are also statuses like "On Hold" that after being done would go back to the status that came before it.

How would this be modeled in DDD?

• Greg Burghardt: Asking how to model something is a pretty big question; probably too big for this community. This would involve a lot of analysis work. Can you edit your question to describe more about what kind of answer you are looking for? Questions usually do better with a narrower focus.

Answer 1

DDD doesn't specify how to model things, it's about keeping your code in the same "language" as the business.

So here you have

Case
 Status CurrentStatus
 Staff AssignedStaffMember
CaseType
 Status[] StatusOrder
Status
 name

Now you have to figure out how you want to code the rules about what happens when you change the state of a case. You code put them in CaseType or Status (although we already know that there arte states with the same name by different rules, so...). DDD doesn't care as long as you don't end up in a new feature request meeting saying "We can't do that because WorkFlows need to be divisible by the nearest prime number..." or something else that departs from the central idea of having Cases with Statuses you move between and by doing so sends emails or assigns staff.

• EMN: If I have an entity called StatusTransitionRule which has properties FromStatus and ToStatus and define all those rules in the database, am I breaking any DDD principles? I guess the rules are business logic. I am doing this because if I tried to code those rules, I would have to write a lot of code and changing them would be difficult.
• Ewan: Yes, Because you might get a new requirement... "for this case type you cant change status on tuesdays" and you would be all "thats hard because StatusTransistionRules cant.. blah blah"