Service policies: interceptors that do one thing

On camera: “Last episode our service was pure business logic. Great — but the auth, logging and tenancy have to live somewhere. That somewhere is a service policy.”

Lower third: “A service policy = an implementation of a horizontal requirement that cuts across services.” Voiceover: “In Chenile, a policy is an interceptor that runs around a service operation.”

Animate a request becoming a ChenileExchange, then passing through a stack of interceptors — security, tenancy, i18n, logging — before reaching the impl, and back out again.

Voiceover, one at a time: (1) One and only one — each interceptor implements a single policy; and only one interceptor owns a given policy, so there’s exactly one place to fix it. (2) Configuration-driven — steered by typed extension keys supplied at deploy time, not hard-coded. (3) Orchestration-unaware — it never assumes its position; it may declare before/after payload, but never hard-wires order.

Voiceover: “Those three rules are what make a policy testable in isolation, reusable across services, and changeable in one place. That’s the opposite of the duplicated plumbing from episode two.”

Show a simple interceptor implementing one policy (e.g. request logging or an error envelope). Attach it via service-registry configuration — no change to the service impl. Call the service; show the policy firing.

Split screen: the old inline version (business logic tangled with a try/catch and a user lookup) vs. the Chenile version (clean impl + one interceptor). “Same behavior. One of these you can reuse.”

“Now the interesting question. If a policy isn’t welded to a service, where should it run? Next: the gateway and the last mile.”

“A policy is a single-responsibility, config-driven, order-agnostic interceptor. Write it once; attach by configuration.”