I am trying to understand how I can make the code for this easy to understand and debug too. The reason I'm asking is that it feels like the kind of scenario which has probably been tackled before plenty of times. And if that is the case I would like to use that as a solid starting point which will allow this to be extended and scale in the future of its lifetime.
Ihave a web application, which needs to performs lots of different actions against an existing external system. The trigger is an action performed in the portal. The order of the steps at design time, and they need to run in order. The actions needed are generally formed of a few steps.
Portal action (Job)A --> (Task A -> Task B -> Task C) Portal action (Job)B --> (Task A -> Task D -> Task E) Portal action (Job)C --> (Task B -> Task D -> Task E) Portal action (Job)D --> (Task C -> Task E) etc, etc.
The steps need to run in order.
While there are technology choices (possibly queuing) within this, the main thing I'm trying to decide on is a code structure.
I have considered a couple of patterns.
- Chain of Responsibility - From what I understand, it seemed like more of a filter for permissions/validation, rather than a method to chain together steps.
- Event Sourcing - To get the benefit, it looked better suited to none sequential execution or possibly multiple subscribers to the same event.
I'm still struggling to accept that I am searching for a pattern that doesn't exist. I'm looking advice on that front, what is the suitable pattern to give me a good solid starting point?