Decision coupling asks which subsystem determines the next action in a process. It becomes a design choice when one subsystem must notify another that work is ready: should it tell the other what to do, or report what happened and let the other decide? section 12.2.2
The message type changes where the decision sits:
- With a command, the sender decides the next action and directs the recipient to perform it. section 12.2.2
- With an event, the sender announces what happened; the recipient decides whether and how to act. section 12.2.2
Completed inspection
After an inspection, the inspections subsystem could command purchasing advice to Generate Advice. Alternatively, it could publish Inspection Completed, leaving purchasing advice to decide to generate advice. If other subsystems also need to know about completed inspections, the event has an advantage: adding another recipient does not require changing its publisher. That makes the event a useful choice for this scenario, not a universal rule. section 12.2.2
Compare the two ways to initiate purchase advice generation, then ask which subsystem should own the decision to proceed. section 12.2.2
To examine decision coupling, trace a concrete scenario through a Domain Message Flow Model. At each handoff, try both a command and an event, then compare their effect on complexity and future consumers. Revisit the choice as requirements and subsystem boundaries evolve. section 12.2.2 section 12.6
