Options for modeling nested/related workflows?

Question

I am working on an application for awarding organizations by the CEO based on a somewhat complex criteria of multiple dimensions. The process consists of 3 nested workflows:

Award workflow (opened → closed → endorsed → approved → published)
Nomination workflow (submitted → reviewed)
Nomination Review workflow (started → finalized → approved/rejected)

The CEO award committee starts the process by opening new awards at the beginning of the year each with its own criteria.

At this point, organizations can start submitting their nominations against these awards which contain all supporting information for why they should win. They can do so until the published award deadline where the award becomes closed.

Each nomination is assigned to a specific reviewer from the committee (one at a time) until they finalize their review and get it approved by the committee chair or otherwise goes for a second or maximum third iteration (i.e. new child workflow usually with another reviewer) of review to verify and score the claimed information in the nomination against the criteria.

When a nomination review workflow is deemed approved, the respective parent nomination workflow is advanced to be reviewed.

And when all nomination workflows are reviewed, the committee can then endorse the award workflow resulting in the semi-final ranking of winners. If approved by the CEO, the workflow becomes approved and ready for publishing the final winners online. If not, the workflow is sent back for further scoring calibrations by the committee.

Now my question is: what options are there for modeling such nested/related workflows? what are the tradeoffs as well?

Do you for example use 1 big saga with one consistent record for each workflow tree?

Or would you use a separate saga for each workflow? How?

Different approach? Different trade-offs?

Answer 1

Model with documentation first

Now my question is: what options are there for modeling such nested/related workflows? what are the tradeoffs as well?

"such nested/related workflows" - you don't seem to be intimately familiar with your requirements yet.

You should be able to design all valid permutations in table in a design document. Attempt to cover all permutations of states, you should find invalid states to leave out.

Then step back and enjoy the clarity.

You should be able to create diagrams, and be able to accurately capture the nuances of the related states. You'll also realise that 2D won't work when doing this. The complexity of your brief above already exceeds that, which is why it's difficult to picture in your mind all at once. Instead of a single-diagram create standalone diagrams that clarify facts about the requirements.

Model the Data next

Your program will need to process data. You might choose to model everything in memory in an OOP way, that's up to you. But you should start with a conceptual relational model, because all data is relational.

Model the Processes last

This actually starts with Humans. They are processes in your system. What data do they need to perform a Process step? What outputs will they generate?

Any other system processes are those that automate instead of a human.

---

I'll skip my first prescribed step, to give you a rough incomplete outline of a possible data-outcome.

Data

• Awards: CriteriaPDF, NominationReviewScoreCardTemplatePDF, NominationDeadlineAt, IsOpen (IsNotClosed), IsEndorsed, IsApproved, IsPublished)
• AwardOpenings: AwardID, OpenedByID, CommitteeMotionPDF
• AwardClosings: AwardID, ClosedByID (Typically with System ID)
• AwardEndorsments: AwardID, EndorsedByID
• AwardPublications: AwardID, PublishedByID
• NewNominations: NominationPitchPDF
• NominationAssessments: NewNominationID, ScoresJSON, ScoresPDF, StartedAt, EndedAt
• ValidNominations: NominationPitchPDF, NewNominationID
• Reviewers: ID, Name
• View_UnassesedNominations

---

Do you for example use 1 big saga with one consistent record for each workflow tree?

Given your OP brief, I think it's too premature for you to start the software implementation design.

Or would you use a separate saga for each workflow? How?

To find boundaries for microservices, you need to complete the requirements analysis and data-design first. After you document the processes, it should become apparent where elements of your system converge into cohesive clusters, with reduced inter-cluster cohesion. That happens last.

Different approach? Different trade-offs?

I believe my approach is already different from what you expected as an answer. Hopefully it's helpful for you.