WJb Docs - Intermediate

🧠 The Core Idea

WJb is built around one simple principle:

Every workflow should be understandable by reading the code.

---

The Problem

Most background job systems eventually become:

Job
 ↓
Pipeline
 ↓
Middleware
 ↓
Retry
 ↓
Magic

When something goes wrong, the questions become hard:

• Why did this job run?
• Who scheduled the next step?
• Why was it retried?
• Where is the workflow logic?

The answers are often spread across configuration, conventions, and framework internals.

---

The WJb Approach

WJb keeps the model flat and visible:

Action
 ↓
Result
 ↓
Next Action

• An Action contains business logic.
• The Result tells WJb what should happen next.
• The next step is scheduled explicitly as a new job.

Nothing is hidden.

---

Explicit Transitions

An action does not call another action.

An action returns a result that describes the next step:

return await NextAsync<LogAction>(
    new LogInput
    {
        Message = "Email sent"
    });

Or finishes the workflow:

return await CompleteAsync();

The transition is ordinary C# code.

---

Why This Matters

When the workflow is explicit:

• Debugging becomes simple
• Testing becomes straightforward
• Reasoning about the system becomes easy
• Onboarding new developers is faster

You can open the action and immediately see:

• What it does
• What it can return
• What runs next

---

Mental Model

Action        = Business Logic
Result        = Outcome
JobCommand    = Next Step
Executor      = Runner
Store         = Persistence

The executor runs the jobs. The actions define the workflow.

---

The Rule

If you cannot explain a workflow by reading the code, the workflow is not explicit enough.

WJb is designed so that you always can.