Framework.Kernel (Framework v0.5.0)

View Source

Generic Kernel implementation providing the canonical flow: Accept → Plan → Commit → Emit → Replay

The Kernel is operation-agnostic and works with any module implementing the Transaction DSL interface. No business operations are hardcoded.

Context Hydration

The Kernel automatically hydrates the context with:

  • Locale - Resolved from input → user → session → header → default
  • Current time - Available via clock_now/0 in plan functions
  • ID generator - Available via id_new/1 in plan functions

Example

ctx = %{
  user: %{locale: "es-ES"},
  session: %{id: "sess_123"}
}

{:ok, result} = Framework.Kernel.accept(
  MyApp.Operations.GreetUser,
  %{user_id: "user_456"},
  ctx,
  %{request_id: "req_789"}
)

# Inside operation plan/2:
# ctx.locale is "es-ES"
# t(ctx, "greeting") returns Spanish translation

Summary

Functions

accept(operation_module_or_atom, input, ctx, ids)

Accept an operation module, input, and hydrated context.

Generic interface - works with any operation module implementing plan/2.

Examples

# Using operation module directly
Framework.Kernel.accept(MyApp.Operations.UserSignup, input, ctx, ids)

# Using operation atom (looks up from registry)  
Framework.Kernel.accept(:user_signup, input, ctx, ids)

Returns {:ok, OperationSettled} | {:error, reason}

append_event(event_type, payload, correlation_ids)

append_event_with_timestamp(event_type, payload, correlation_ids, timestamp)

commit(plan, ids)

Execute the single transactional commit derived from the plan.

Generic commit implementation that works with any plan structure produced by Transaction DSL operations.

compile(operation_module, input, ctx \\ %{})

Generic plan compilation - delegates to operation module's plan/2 function.

The kernel doesn't know about specific operations - it just calls plan/2 on any module that implements the Transaction DSL interface.

emit_from(cursor)

emit_from_impl(cursor)

replay_from(cursor)

replay_from_impl(cursor)