How to assign a request to different people dependent on request type and initiator in DDD - domain-driven-design

Question

I am working on a project and want to try to adhere to DDD principles. As I've been going about it I've come across some questions that I hope someone will be able to help me with.
The project is a request system with each request having multiple request types inside it.
When a request is submitted it will be in a status of AwaitingApproval and will get routed to different people sequentially according to a set of rules as below:-
1) If the request only contains request types that don't need
intermediate approval it will be routed to a processing department
who will be the one and only approval in the chain.
2) If the initiator of the request is a Level 1 manager it will require
approvals from Level2, Level 3 and Level 4 managers
3) If the initiator is a Level 2 manager the request will be as 2) but without the need for Level 2 approval for obvious reasons
4) If the request contains a request type that increases a monetary value by lets say >$500 it will require the approval of a Level 4 manager
A request at any of the stages can either be Approved, Rejected or Rejected With Changes. Approve it will take it take the next level in the approval chain. Reject ends the process entirely.
Reject With Changes allows the user to send back to any of the previous approvers of the request as appropriate who will then be able to do the same with an Approve potentially sending it back through the chain again if it was a monetary change or if the reject with changes came from the processing department it will be re-assigned straight back to them.
Initially, I considered that we had an aggregate route of a Request with a RequestStatus using the State Pattern.
So I would have something like
class Request{
_currentstate = new AwaitingApprovalState();
void AssignTo(string person){
_assignee = person;
}
void Approve(){
_currentstate = _currentstate.Approve();
}
}
class AwaitingApprovalState : IState{
void Approve(){
return new ApprovedState();
}
}
class ApprovedState : IState{
void Approve(){
return new Level2ManagerApprovedState();
}
}
This got me to a point but I kept getting caught in knots. I think I am missing something in my initial model.
Some questions that occur
1) Where does the responsibility of working out who the next manager in the chain is to assign the request? Does that belong in the state class implementations or somewhere else like on the Request itself?
2) Currently a new request is in AwaitingApprovalState and if I approve it goes straight to ApprovedState. Where does the logic go that determines that because I don't require any intermediate approvals it should go straight to the processing department?
3) If there is a reject with modifications how do we go back to previous levels - I have considered some sort of StatusHistory entity.
I have considered maybe that this is some sort of workflow component but want to avoid that as much as possible.
Any pointers or ideas would be very much appreciated

Answer 1

If often makes sense to model processes as histories of related events. You might imagine this as a log of activity related to a specific request. Imagine somebody getting messages from different departments, and writing down the messages in a book
Request #12354 submitted.
Request #12354 received level 2 approval: details....
Request #12354 received level 3 approval: details....
To figure out what work needs to be done next, you just review what has already happened. Load all of the events, fold them into an in memory representation, and then query that structure.
Where does the responsibility of working out who the next manager in the chain is to assign the request?
Something like that would probably be implemented in a domain service; if the aggregate doesn't contain the information that it needs to do work, then it has to ask somebody else.
A common pattern for this would be a "stateless" service that knows how to find the right manager, given a set of values which describe the state of the aggregate. The aggregate knows what state it is in, so it passes the values describing its state to the service to get the answer.
Manager levelFourManager = managers.getLevelFourManager(...)
Where does the logic go that determines that because I don't require any intermediate approvals it should go straight to the processing department?
Probably into the aggregate itself, eventually.
Rinat Abdullin put together a very good tutorial on evolving process managers, which is very much in line with Greg Young's talk Stop Over Engineering.
You've got some query in your model like
request.isReadyForProcessing()
In the early versions of your model, the request might answer false until some human operator has told it that "yes, you are ready"; then, over time you start adding in the easy cases to compute.
boolean isReadyForProcessing() {
return aHumanSaidImReadyForProcessing() || ImOneOfTheEasyCasesToProcess();
}
What "send to processing" actually means probably doesn't live in the aggregate. We might borrow the domain service idea again, this time to communicate with an external system
void notify(ProcessingClient client) {
if (this.isReadyForProcessing()) {
client.process(this.id);
}
}
The processing client might be doing real work, or it might just be sending a message somewhere else -- the aggregate model doesn't really care.
Part of the point of domain model, as a pattern, is that our domain calls for the coordination/orchestration of messages between objects in the model. If we didn't need that complexity, we'd probably look at something more straight forward, like transaction scripts. The printed version of Patterns of Enterprise Application Architecture dedicates a number of pages to describing these.
If there is a reject with modifications how do we go back to previous levels - I have considered some sort of StatusHistory entity.
Yes, that -- RejectWithModifications is just another message to write into the book, and that gives you more information to consider when answering questions.
Request #12354 submitted.
Request #12354 received level 2 approval: details....
Request #12354 received level 3 approval: details....
Request #12354 rejected with modifications: details....
I understand what you're saying and it makes great sense. I still get caught up in implementation details.
That is not your fault.
The literature is weak.
does the log of events lets call it ActivityLog live on the Request aggregate or is its own aggregate like in the Cargo DDD samples?
Putting it into the aggregate is probably the right place to start; it might not stay there. Finding a decent local minimum for your current system is probably better than trying to find the global minimum right away.
Are there differences between domain events as per Evans in the blue book and more recent domain events.
Maybe; it's also tangled because domain events aren't necessarily the sort of thing people are talking about when they say "event sourcing".
Need to see the wood for the trees.
The only thing that has worked for me, is to regularly go back to first principles, working through solutions piece by piece, and watching like a hawk for implicit assumptions.

Answer 2

1) Where does the responsibility of working out who the next manager
in the chain is to assign the request? Does that belong in the state
class implementations or somewhere else like on the Request itself?
It depends. It could be in Request itself, it could be in a Domain Service.
As an aside, I would recommend, if feasible, not determining exactly who the next validator is when the Request transitions to its next state but later. Sending a notification and displaying the validation request on a dashboard are consequences of domain state changes but not state changes per se - they don't need to happen atomically with the operation on Request but can happen at a later time.
If you manage to dissociate the bit that looks up validator data for request followup from the logic that determines who the next type of validators is (Level1 manager, Level 2 manager, etc.) you will probably spare yourself some complex modelling of the Request aggregate.
2) Currently a new request is in AwaitingApprovalState and if I
approve it goes straight to ApprovedState. Where does the logic go
that determines that because I don't require any intermediate
approvals it should go straight to the processing department?
Same as 1)
3) If there is a reject with modifications how do we go back to
previous levels - I have considered some sort of StatusHistory entity.
You could either work out who the previous validation group was, using the same kind of logic as for determining the next group. Or you could store a history of past states as a private member of Request alongside _currentState

Answer 3

for explaining this lets make assumption that there are there types of request types:
Purchase (require manager approval, eg: level 2 require level 3 and above managers approval)
BusinessMeet (No Approval Needed)
and as we can see there are diff. type of requests with diff. approval cycle and more such type of requests will be added in future.
Now lets see for the current structure how we would define it in DDD:
PurchaseRequest Aggregate extends RequestAgg
requestid
requested by
purchase info - description about purchase
requested by manager level
pending on mangers lists -- list of manager with level
approved by mangers lists -- list of manager with level
next manager for approval -- manager with level
status {approved , pending}
BusinessMeetRequest Aggregate extends RequestAgg
requestid
requested by
status {approved , pending} -- by default it should be approved
ApprovalRequestAgg
requestid
manager id
request type
status - (Approved , Rejected)
When user request he either hit api with purchase request or BusinessMeetRequest
In this case lets say user hit with purchase request then PurchaseRequestAgg will be created.
Based on the event PurchaseRequestCreated one ProcessManager will listen to the event and create a new agg ApprovalRequestAgg which has the manager id.
Manager will be able to see the request which it needs to approve from ApprovalRequest Read Model. and to see the info of request as ApprovalRequest has the request id and request type he will be able to fetch the actual purchase request, after this he can either approve or reject and send a event ApprovalRequestRejected or ApprovalRequestApproved.
Based on the above event one will update the PurchaseRequestAgg. and PurchaseRequest Agg will give a event (lets say after approval) PurchaseRequestAcceptedByManager.
Now someone will listen and the above loop work.
**In the above solution only problem is adding a new type of request will take time **
Another way could be there is a single RequestAgg. for request
RequestAgg
- request id
- type
- info
- status
and the algo for giving update to the manager is written in ProcessManager.
I think this would help you. if still has doubts , ping again :)