DDD和企业架构之间的共识

DDD和SOA配合得很好。通常，服务边界与有边界的上下文相匹配。您使用SOA设计跨上下文通信，一切都可以。EA并没有深入探讨您如何在内部开发"服务"，但DDD可以帮助您。

对我来说，DDD的最大优势是它可以让你在分析业务领域时完成工作。

对该领域的良好理解从来都不是坏事，当然，这句话对SOA也是正确的。更重要的是，如果您能够为大多数实体构建一个通用的数据模型，这将提高互操作性，因为您将能够构建更标准化的服务，从而避免数据映射和转换的需要。当您进行服务组合和/或编排时，常见类型往往成为必须的。因此，如果你在前期投入更多的工作，那么当你的服务和库存进入治理阶段时，你会过得更轻松。

正如Alexey已经指出的，DDD和SOA不会相互干扰，并且可以很好地协同工作。

在他的书《SOA设计模式》中，Thomas Erl描述了软件最终是如何由可能与技术、平台或资源相关的架构元素组成并驻留在其中的。然后，他解释了技术体系结构在面向服务中的重要性，它有四种常见类型：

1. 服务体系结构
2. 服务组合体系结构
3. 服务清单体系结构
4. 面向服务的企业体系结构

就技术架构而言，没有提及应该如何实现服务(DDD或其他)。它只是强调它们的存在，它们的可组合性和它们的边界。

领域驱动设计，涵盖了软件组件设计的"方式"。这正是书中发生的事情。当叙述转向设计模式时，领域清单和实体抽象等主题就会出现在画面中。

因此，只要设计方法符合SOA的四个特征(业务驱动、供应商中立、以企业为中心、以组合为中心)及其设计原则(标准化服务契约、服务松耦合、服务抽象、服务可重用性、服务自治、服务无状态、服务可发现性和服务可组合性)，在我看来DDD确实如此，它可以安全地用于软件及其服务的设计和实现。