DDD与企业架构之间的共识

Question

在文献（关于企业架构的博客，文章，书籍......）中，似乎EA中存在一个真实（且独有）的SOA设备。如果我们认为DDD和SOA共享共同的架构原则但在许多其他原则上有所不同，那么DDD在EA学科中的位置是什么？

Answer 1

DDD和SOA一起发挥得很好。通常服务边界与您的有界上下文匹配。您使用SOA设计跨上下文通信，这一切都有效。 EA没有深入探讨如何开发您的服务＆＃34;在里面，DDD可以帮助你。

Answer 2

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

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

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

领域驱动设计，涵盖软件组件设计的“方式”。而这正是本书中发生的事情。当叙述摆动到设计模式时，域名清单和实体抽象等主题就会出现。

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

Answer 3

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

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

识别（类型）------范围------计划者的感知---- ZF排

定义（业务）---概念------所有者感知-----------第二行ZF

代表（系统）----逻辑---------建筑师的认知-------第三排ZF

指定（技术）-物理--------工程师的认知--------第四排ZF

配置（工具）-----实现–分包商感知–行V ZF

清单（操作）-说明---操作员感知--------第六行ZF

换句话说，DDD作者弄错了，他把苹果和橘子混在一起。基本上，早在2000年代初他撰写DDD书时，他就不熟悉EA研究（Zachman Framework的第一个版本于80年代末发布，但在相当长的一段时间内并未在商业社区中泛滥）。 >