Command bus pattern for trasnaction, logging, idempotency handling.

[dbealthy]

I recently ran into a design question while implementing idempotency for a few use cases (for example, CreateOrder).
The requirement is simple: the client sends an idempotency key, and within a single transaction we persist both the idempotency record and the order itself. If the same key is sent again, we return the previous result.

The problem is where this logic should live.
In our current flow:

controller -> interactor (via di) -> business logic

there’s no obvious place to attach reusable cross-cutting concerns like idempotency. The options I see are:

Decorate command handlers in the di

Put idempotency logic directly inside each handler

Neither feels very clean. Idempotency is clearly a cross-cutting concern, but with this structure it ends up either tightly coupled to handlers or awkwardly wired through DI.

Transaction management makes it even trickier. Since we want idempotency and business logic to run in a single transaction, we either push transaction handling into handlers or end up dealing with nested transactions which also doesn’t feel right.

This makes me think: would introducing a command bus help here?

With a command bus, we could add middleware for:

Idempotency
Transaction management
Other cross-cutting concerns

Handlers would stay focused purely on business logic, and middleware could handle things like transactions and idempotency in a consistent way.

I’m curious how others are approaching this, especially in Clean Architecture / DDD-style applications. Does a command bus make sense here, or is there a cleaner way to structure this without adding extra abstraction?

[ivan-borovets]

Hi! I might not fully understand the question, but if cross-cutting logic is truly shared across many interactors - there's a pattern called command processor (essentially a decorated interactor). An example implementation can be found in https://github.com/chessenjoyer17/bazario. As for idempotency keys specifically - not ready to give general advice on that...