Request Processing Units

A Request Processing Unit, or RPU, implements one Domain Capability.

It has one public shape:

process(request) -> response

The request enters the RPU. The response leaves the RPU. Everything else is internal.

[ Domain Request ]  →  ( RPU / one domain capability )  →  [ Domain Response ]

Domain Capability

An RPU implements exactly one Domain Capability.

The capability is a command or a query. A command decides and may change the domain; a query answers a question and returns a result. Commands and queries stay separate.

The Domain Capability page defines the capability itself. This page describes how one capability is implemented as a unit.

Public Surface

The public surface of an RPU is its request and response.

The caller does not see the internal state, persistence mechanism, decision structure, or implementation files.

The RPU boundary is the coordination boundary.

Other code depends on the request and response contract, not on the internal implementation.

Internal Structure

An RPU is built as a Functional Core / Imperative Shell.

The request enters through the Imperative Shell. The shell loads the context and passes the command and the context into the Functional Core. The Functional Core decides. The shell records the consequences into the Application State and returns the response.

The RPU as a whole is not pure. The core is; the shell holds the effects.

Command RPU

A command RPU processes a request that can change the domain.

A command RPU should contain everything needed for that command capability.

It does not call another RPU.

It owns the complete processing path for its capability.

Query RPU

A query RPU processes a request that reads from the domain.

A query RPU returns the result needed by the caller.

Larger transformations that belong to the domain should live inside a query RPU, not outside the domain boundary.

Independence

An RPU is independently understandable, implementable, and testable.

It owns one capability.

It has one request and one response.

It does not depend on other RPUs.

Its internal state access can be replaced for tests.

This independence allows different capabilities to be developed in parallel without sharing internal code or state.

Summary

An RPU is:

• one domain capability
• one process(request) -> response contract
• self-contained
• independent of other RPUs
• internally structured as Functional Core / Imperative Shell
• testable without a user interface
• focused on domain behavior, not technology