Deductive and Inductive Interfaces: From User Gesture to Business Command

Greg Young , in his foundational documents on CQRS, introduces an enlightening distinction between two interface styles.

Greg Young’s Distinction

• A deductive interface presents raw data to the user and leaves them free to modify it as they see fit: think of a form with editable fields where one submits a final state.
• An inductive interface, in contrast, guides the user through specific and intentional actions: buttons like “Approve”, “Reject”, “Ship” that capture an intention rather than a data delta.

This distinction, seemingly cosmetic, has profound repercussions on the entire application architecture.

The Deductive Interface and Its Limits

The deductive interface naturally leads toward generic CRUD operations. The user modifies an object, the frontend calculates a diff or sends the complete state, and the backend must deduce what the user really wanted to do.

“The status changed from ‘pending’ to ‘approved’: ah, so it’s an approval.”

This inference is fragile:

• It loses the original intention
• It complicates business validation
• It makes the audit trail opaque

Worse, it tightly couples the interface structure to the entity structure, making any evolution of the domain model painful.

The Inductive Interface: Capturing Intention

The inductive interface captures the intention at the very moment the user expresses it.

A click on “Approve Order” generates a command (in the CQRS sense):

ApproveOrder { orderId, approverId, comment }

This command traverses the system with its semantics intact. The backend has nothing left to deduce: it directly receives a clear order that it can validate, execute, and log.

Use cases become explicit business verbs rather than generic persistence operations. We find here the essence of task-based UI: the interface reflects the tasks the user accomplishes, not the structure of the data they manipulate.

End-to-End Alignment

This approach establishes a remarkable end-to-end alignment:

1. The domain expert speaks of “approving an order”
2. The UX designer creates an “Approve” button
3. The frontend emits an ApproveOrder command
4. The backend exposes an ApproveOrderHandler
5. The aggregate implements an approve() method
6. The OrderApproved event is emitted

The same vocabulary, the same granularity of intention, traverses all layers. This is ubiquitous language taken to its logical conclusion: not only in server code, but all the way to the user interface.

Business use cases are no longer ideas documented here and there in the form of diagrams or vague descriptions, but concrete and traceable artifacts directly in the code.

This explicit capture of intention is also a goldmine for product analytics. When every user action is a named command (ApproveOrder, RejectClaim), logs are structured by construction. “How many orders were approved this month?” becomes a trivial query, not a data science project.

Consequences on Design

The consequences on design are considerable:

• On the read side: we can build projections optimized for each screen, freed from the constraints of a normalized data model
• On the write side: each command can carry exactly the data necessary for its validation, no more, no less

Evolution becomes safer: adding a new business action means adding a new command, a new handler, a new button: without touching existing flows.

We thus avoid the syndrome of the omniscient form that tries to do everything and ends up doing everything poorly.

The inductive interface is not just a UI pattern: it’s a design philosophy that recognizes that business systems are made of intentional actions, not arbitrary data mutations.

It’s also an audit trail by construction. Regulators, security teams, compliance officers: all are satisfied by immutable event logs that capture exactly what happened and why.