2

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

4

4 回答 4

5

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

于 2015-04-30T08:51:18.787 回答
1

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

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

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

于 2015-04-30T15:51:55.500 回答
1

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

  1. 服务架构
  2. 服务组合架构
  3. 服务库存架构
  4. 面向服务的企业架构

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

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

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

于 2015-05-02T06:26:50.107 回答
-1

DDD，正如一位 EA 大师（我相信是 Gary Booch）曾经说过的，是 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 年代后期发布，但在相当长的一段时间内它并没有在商业社区中普及）。

于 2019-02-07T00:30:40.583 回答