AI curriculum

Course outline for Event-Driven Workflow Design

Duplicate or delayed messages can trigger invalid actions and obscure a request's history. Design a bounded event-driven request workflow with explicit commands, versioned events, and state transitions. Reconstruct historical state without replaying external effects.

Technology: Workflow Engineering
Duration: 6 hours
Modules: 3 · 2 hours each
Level: Level 2

About Event-Driven Workflow Design

Event-Driven Workflow Design Course Objectives

Distinguish commands, events, and read-model queries.
Define allowed state transitions and separately enforced action permissions.
Replay versioned events into a historical projection.
Handle duplicate and out-of-order messages using explicit rules.
Distinguish correlation, recorded causal links, and conclusions unsupported by the event record.

Pre-requisites

Ability to model workflow activities, states, and handoffs.
Familiarity with APIs and basic programming or system design.

Before this course

Complete the required courses or bring equivalent experience. Recommended courses add useful depth; they are not enrolment gates.

Required preparation

Workflow Foundations for AI Automation

Recommended preparation

Can model activities, objects, states, and handoffs; software and database background help with commands, projections, and replay.

Find your place in the learning map

Lab Setup

Computer with a diagram editor and programming runtime.
Supplied synthetic message histories, expected projections, and a local event simulator with a mock action sink.
No hosted broker, real mailbox, or external send permission is needed.

Detailed Course Outline

Module 1: Define messages and permitted transitions

Events: Define versioned records of business occurrences with source identifiers, effective time, and recorded time for historical interpretation.
Commands: Distinguish requested actions from recorded events and read queries; check caller permissions separately from legal state transitions.
State transitions: Specify allowed request changes and reject premature actions without assuming that a legal transition grants caller authority.
Event-driven architecture: Assign command handling, event publication, and read projections explicit responsibilities while accounting for delayed and duplicate messages.

Practical outcome: Specify command/query responsibilities, event versions, a transition table, and a separate caller/action permission check outside the model.

Module 2: Rebuild state without repeating actions

Event sourcing: Reconstruct historical request state from versioned events while preventing replay from repeating previously performed external actions.
Triggers: Map qualifying events to actions with duplicate suppression, distinguishing projection replay from authorization to execute effects.
Reactive workflows: Advance request processing in response to messages using explicit ordering rules and a documented late-event policy.

Practical outcome: Replay a request history into a read projection, distinguish effective and recorded time, and suppress duplicate triggers.

Module 3: Trace a long-running request

Long-running processes: Track a request across incoming messages, drafting, approval, and action records without losing state between delayed steps.
Correlation: Associate related messages and artifacts through stable request identifiers without treating shared identifiers as evidence of causation.
Causality: Distinguish recorded cause links from correlation and temporal order, documenting conclusions that incomplete event histories cannot support.

Practical outcome: Link a message, draft, approval, and recorded action by identifiers while documenting missing evidence and late-event policy.

Practical exercise

Complete supplied message contracts, a transition table, and a local projection for synthetic incoming requests.
Process a valid message through draft and approval; reject an action before approval, an unauthorized caller at a legal transition, and an incompatible event version.
Replay duplicate and reordered fixtures under the supplied ordering policy; assert the expected projection and unchanged mock action count during replay.
Produce a historical read view with source identifiers, both timestamps, and explicit limits on causal interpretation.

What you will produce

Design and replay a bounded event workflow with explicit transition and duplicate-handling rules.

How the work is checked

Illegal transitions, unauthorized callers at legal transitions, and incompatible event versions are rejected without changing protected state.
Duplicate and reordered fixtures yield the documented projection under the stated ordering policy.
Projection replay does not repeat mock external effects.
Historical views distinguish recorded time, effective time, and evidence limits.

Six-hour local simulation; command/query separation is not authorization, and event records do not prove causal impact or production broker guarantees.

When another approach is better

Prefer a synchronous operation when a request has no independent consumers or long-running coordination.
Avoid event sourcing when historical reconstruction does not justify event-version and projection maintenance.

How we train

Ask about exercises, instructor feedback and the prior knowledge you need. Tool-specific courses marked provisional may become modules in a broader course.

Discuss your learning goals