DDD与企业架构的共识答案

【问题标题】：Consensus between DDD and Enterprise ArchitectureDDD与企业架构的共识
【发布时间】：2015-07-09 19:06:17
【问题描述】：

在文献（博客、文章、有关企业架构的书籍...）中，似乎在 EA 中存在一个真正的（和专有的）SOA 应用。如果我们认为 DDD 和 SOA 具有共同的架构原则，但在许多其他方面存在差异，那么 DDD 在 EA 学科中的位置是什么？

【问题讨论】：

标签： architecture domain-driven-design enterprise architectural-patterns

【解决方案1】：

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

【讨论】：

【解决方案2】：

对我来说，DDD 的最大优势在于它可以让您在分析业务领域时做好自己的工作。

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

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

【讨论】：

【解决方案3】：

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

服务架构
服务组合架构
服务清单架构
面向服务的企业架构

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

领域驱动设计，涵盖软件组件设计的“方法”。这正是书中发生的事情。当叙述转向设计模式时，诸如域清单和实体抽象之类的主题就出现了。

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

【讨论】：

【解决方案4】：

正如一位 EA 大师（我相信是 Gary Booch）曾经说过的，DDD 是 DDD 作者对 EA 误解的结果（在他的 DDD 书中，他混合了概念、逻辑、物理、实现等概念，和操作感知 - 一件非常非常危险的事情！）。

基本上，当您谈论 EA 时，您必须始终辨别不同的观点（借用 Zachman EA 框架中的术语）并在 EA 的特定阶段中您关注的特定观点的边界内对架构进行建模发展过程。例如

识别（类型）-----SCOPE--------计划者感知----Row I ZF

定义（业务）-----CONCEPTUAL------业主认知-----------Row II ZF

表示（系统）----LOGICAL---------架构师感知-------Row III ZF

指定（技术）--PHYSICAL--------工程师感知--------Row IV ZF

配置（工具）--实施--分包商感知--Row V ZF

Manifest（操作）-INSTANTIATION---操作员感知--------Row VI ZF

换句话说，DDD 作者完全错了，他把苹果和橘子混为一谈。基本上，早在 2000 年代初他写 DDD 书时，他对 EA 研究并不熟悉（Zachman 框架的第 1 版于 80 年代末出版，但在很长一段时间内都没有在商业界普及）。

【讨论】：

多么可怕的答案！我假设您在提到“作者”时是指 Eric Evans，顺便说一句，其他人的名字是 Grady Booch。