Command Pattern: Encapsulating Actions and Requests in Scala

Command pattern: A behavioral pattern that represents an action or request as a value that can be passed around, stored, queued, retried, or interpreted later.

Scala is especially good at Command because actions can be modeled cleanly as case classes or as small functions, depending on whether the important thing is durable intent or immediate behavior.

Command as Data vs Command as Function

There are two common Scala shapes:

• command as data when the action needs to be logged, validated, serialized, retried, or replayed
• command as function when the action is short-lived and in-memory

If intent must survive beyond one call stack, data is usually the stronger model.

1sealed trait UserCommand
2final case class RegisterUser(email: String) extends UserCommand
3final case class DisableUser(id: UserId) extends UserCommand

Now the system can validate, persist, route, or audit the command before execution.

Handlers Keep Execution Separate From Intent

One clean Scala pattern is to separate command representation from command handling:

1trait CommandHandler[C, R] {
2  def handle(command: C): Either[String, R]
3}

This creates a clear boundary:

• commands describe what should happen
• handlers know how to make it happen

That is useful in message-driven systems, job queues, UI action models, or domain command processing.

Use Functions for Localized Immediate Commands

If the command is purely local and ephemeral, a function can be enough. This works well for:

• menu actions
• UI callbacks
• local orchestration steps
• test-time injected behavior

But once you need durable intent, typed command values usually age better than anonymous functions.

Command Often Connects to Auditing and Retries

The pattern becomes especially valuable when the action needs lifecycle:

• enqueue now, execute later
• store and replay after recovery
• retry under policy
• inspect or audit before execution

That is where “command as data” clearly beats a direct method call.

Be Careful Not to Overwrap Trivial Behavior

Not every method call needs a command object. If the action is:

• immediate
• local
• not queued
• not validated separately
• not logged or replayed

then direct method invocation may be simpler.

Common Failure Modes

Wrapping Every Method in a Command Type

The design adds ceremony without gaining lifecycle benefits.

Mixing Validation, Routing, and Execution Everywhere

Commands become unclear because too much command logic is scattered across the system.

Using Untyped String Commands

The pattern loses one of its strongest Scala benefits: explicit intent as typed data.

Practical Heuristics

Use Command when an action should become an explicit unit of intent. Prefer case classes for durable or auditable commands, functions for short-lived local behavior, and keep the separation between intent and execution sharp.

Ready to Test Your Knowledge?