服务组合是 SOA 的基本组成部分。服务清单提供的所有功能都有望在必要时利用该清单中的其他服务，以构建它们从较小的组件部分完成的任务。不过，这一切都来自架构级别：这种组合是如何在实现级别发生的？
考虑这种情况。我有一个“任务服务”，它涉及发布一个/process-request资源，该资源将管理异步处理大文件以生成“真实”资源所涉及的其他资源。我们将最终的“真实”资源称为 PartsInventory。因此，您向服务提供了 PartsInventory 的 URL 和名称/process-request，然后该服务创建 PartsInventory“占位符”并启动异步 ETL，将 URL 中的大量 csv 文件转换为真实的 PartsInventory。如果此异步作业失败，它将删除占位符，并且对/process-request服务的查询将反映失败。如果成功了，/process-request
现在，
从代码的角度来看，PartsInventory/process-request和 PartsInventory之间的交互实现如何？我是在向已发布的
服务发送请求，还是在调用 ORM 对象来创建占位符？如果是前者，我将遵守已发布的合同，并且表现得像我自己的服务的消费者，这似乎符合可组合性原则——但在同一个代码库中以这种方式进行交互感觉真的很尴尬。另一方面，后者假定处理程序将知道如何自行创建 PartsInventory 占位符，这本身就很尴尬。第三个选项是在 PartsInventory 对象上创建一个专门的静态工厂方法，称为类似的东西，以便
/parts-inventory/process-requestPartsInventory.create_placeholder()/process-request代码至少不知道 PartsInventory 对象的构造函数依赖项。不过，这仍然将创建分为两个位置。
你遇到过这种情况吗？这个问题有规范的“正确答案”吗？