DDD与企业架构的共识
Consensus between DDD and Enterprise Architecture
在文献（关于企业架构的博客、文章、书籍...）中，似乎在 EA 中有一个真实的（且独有的）SOA 应用程序。如果我们认为 DDD 和 SOA 共享共同的架构原则但在许多其他原则上有所不同，那么 DDD 在 EA 学科中的位置是什么？
DDD 和 SOA 配合得很好。通常服务边界与您的限界上下文相匹配。您使用 SOA 设计跨上下文通信并且一切正常。 EA 不会深入探讨您如何在内部开发 "services"，但 DDD 可以帮助您。
对我来说，DDD 的最大优势在于它让你在分析业务领域时做好自己的工作。
对领域的良好理解从来都不是坏事，当然这句话对于 SOA 也适用。更重要的是，如果您设法为大多数实体构建通用数据模型，这将提高互操作性，因为您将能够构建更加标准化的服务，从而避免数据映射和转换的需要。当您进行服务组合时 and/or 编排常见类型往往成为必须的。因此，如果您在前期投入更多工作，那么当您的服务和库存进入治理阶段时，您将会过得更轻松。
正如 Alexey 所说，DDD 和 SOA 不会相互干扰并且可以很好地协同工作。
在他的 SOA 设计模式一书中，Thomas Erl 描述了软件最终如何由与技术、平台或资源相关的架构元素组成并驻留在其中。然后他解释了技术架构在面向服务中的重要性及其四种常见类型：
- 服务架构
- 服务组合架构
- 服务库存架构
- 面向服务的企业架构
就技术架构而言，没有提到服务应该如何实现（DDD或其他）。它只是强调它们的存在，它们的可组合性和它们的边界。
领域驱动设计，涵盖"how"软件组件设计。这正是书中发生的事情。当叙述转向设计模式时，领域清单和实体抽象等主题就会出现。
因此，只要设计方法符合 SOA 的四个特征（业务驱动、供应商中立、以企业为中心、以组合为中心）及其设计原则（标准化服务契约、服务松散耦合、服务抽象、服务可重用性） 、服务自治、服务无状态、服务可发现性和服务可组合性），在我看来 DDD 确实如此，它可以安全地用于软件及其服务的设计和实现。
DDD，正如一位 EA 大师（我相信是 Gary Booch）曾经说过的那样，是 DDD 作者对 EA 的误解的结果（在他的 DDD 书中，他混合了概念、逻辑、物理、实施和运营观念 - 非常非常危险的事情！）。
基本上，当您谈论 EA 时，您必须始终区分不同的观点（借用 Zachman EA Framework 中的术语）并在特定阶段的特定观点的边界内对架构进行建模EA开发过程。例如
识别（类型）-----SCOPE--------Planner perception----Row I ZF
Define (business)-----CONCEPTUAL-----Owner perception------------Row II ZF
代表（系统）----LOGICAL--------架构师感知--------Row III ZF
指定（技术）--PHYSICAL--------工程师感知--------ZF排IV
Configure（工具）-----IMPLEMENTATION--分包感知--Row V ZF
Manifest(operations)-INSTANTIATION---操作员感知--------Row VI ZF
换句话说，DDD作者完全错了，他把苹果和橘子混在一起了。基本上，回到 2000 年代初期，当他写 DDD 这本书时，他对 EA 研究并不熟悉（Zachman Framework 的第一个版本发布于 80 年代末，但它在相当长的一段时间内没有在商业社区中普及）。
在文献（关于企业架构的博客、文章、书籍...）中，似乎在 EA 中有一个真实的（且独有的）SOA 应用程序。如果我们认为 DDD 和 SOA 共享共同的架构原则但在许多其他原则上有所不同，那么 DDD 在 EA 学科中的位置是什么？
DDD 和 SOA 配合得很好。通常服务边界与您的限界上下文相匹配。您使用 SOA 设计跨上下文通信并且一切正常。 EA 不会深入探讨您如何在内部开发 "services"，但 DDD 可以帮助您。
对我来说，DDD 的最大优势在于它让你在分析业务领域时做好自己的工作。
对领域的良好理解从来都不是坏事，当然这句话对于 SOA 也适用。更重要的是，如果您设法为大多数实体构建通用数据模型，这将提高互操作性，因为您将能够构建更加标准化的服务，从而避免数据映射和转换的需要。当您进行服务组合时 and/or 编排常见类型往往成为必须的。因此，如果您在前期投入更多工作，那么当您的服务和库存进入治理阶段时，您将会过得更轻松。
正如 Alexey 所说，DDD 和 SOA 不会相互干扰并且可以很好地协同工作。
在他的 SOA 设计模式一书中，Thomas Erl 描述了软件最终如何由与技术、平台或资源相关的架构元素组成并驻留在其中。然后他解释了技术架构在面向服务中的重要性及其四种常见类型：
- 服务架构
- 服务组合架构
- 服务库存架构
- 面向服务的企业架构
就技术架构而言，没有提到服务应该如何实现（DDD或其他）。它只是强调它们的存在，它们的可组合性和它们的边界。
领域驱动设计，涵盖"how"软件组件设计。这正是书中发生的事情。当叙述转向设计模式时，领域清单和实体抽象等主题就会出现。
因此，只要设计方法符合 SOA 的四个特征（业务驱动、供应商中立、以企业为中心、以组合为中心）及其设计原则（标准化服务契约、服务松散耦合、服务抽象、服务可重用性） 、服务自治、服务无状态、服务可发现性和服务可组合性），在我看来 DDD 确实如此，它可以安全地用于软件及其服务的设计和实现。
DDD，正如一位 EA 大师（我相信是 Gary Booch）曾经说过的那样，是 DDD 作者对 EA 的误解的结果（在他的 DDD 书中，他混合了概念、逻辑、物理、实施和运营观念 - 非常非常危险的事情！）。
基本上，当您谈论 EA 时，您必须始终区分不同的观点（借用 Zachman EA Framework 中的术语）并在特定阶段的特定观点的边界内对架构进行建模EA开发过程。例如
识别（类型）-----SCOPE--------Planner perception----Row I ZF
Define (business)-----CONCEPTUAL-----Owner perception------------Row II ZF
代表（系统）----LOGICAL--------架构师感知--------Row III ZF
指定（技术）--PHYSICAL--------工程师感知--------ZF排IV
Configure（工具）-----IMPLEMENTATION--分包感知--Row V ZF
Manifest(operations)-INSTANTIATION---操作员感知--------Row VI ZF
换句话说，DDD作者完全错了，他把苹果和橘子混在一起了。基本上，回到 2000 年代初期，当他写 DDD 这本书时，他对 EA 研究并不熟悉（Zachman Framework 的第一个版本发布于 80 年代末，但它在相当长的一段时间内没有在商业社区中普及）。