编排与编制的清晰定义，及依赖方向决定耦合发生位置

“编排”和”编制”没有全球公认的简明定义，作者在本书语境下给出明确界定：命令驱动通信=编排，事件驱动通信=编制。编排的本质是”协调活动或任务”，不局限于工作流引擎——任何组件只要协调一个或多个其他组件，就是在做编排，表现为它会发送命令；编制则是组件为了完成某些事情，以事件驱动的方式直接和其他组件交互。这个定义有个重要推论：它只针对单条通信链路，而不是描述整个系统——”设计一个编制系统”这种说法本身就没有意义，好的架构里编排和编制通常同时存在，很多时候是不知不觉混合出来的（比如”只是”调用了另一个服务时其实就在做编排）；作者本人更愿意直接谈”基于事件的交互”或”基于命令的交互”，因为编排/编制这两个术语制造的混乱往往比它们解决的问题还多。这个定义还揭示了编排和编制在耦合方向上的根本差异：使用事件时，作为接收方要知道在哪个通道接收事件、事件含义是什么、附加数据是什么结构，因此耦合发生在接收方，依赖方向是从接收方指向发送方；使用命令时，发送方必须知道命令含义、发到哪个通道、带什么数据，耦合发生在发送方，依赖方向是从发送方指向接收方。两个组件通信必然产生一定程度的领域耦合，无法避免，但你可以主动选择让耦合落在哪一侧——这正是选事件还是选命令的本质。

结构图：

flowchart LR
    subgraph 编排["编排=命令驱动通信"]
        A1[发送方A] -->|命令,需知道通道/语义/数据结构| B1[接收方B]
        A1 -.耦合方向: 发送方依赖接收方.-> B1
    end
    subgraph 编制["编制=事件驱动通信"]
        C1[发送方C] -->|事件,不关心谁响应| D1[接收方D]
        D1 -.耦合方向: 接收方依赖发送方的事件语义.-> C1
    end