DDD与企业体系结构的共识

Question

在文献(博客、文章、关于企业架构的书籍.)中，SOA在EA中似乎有一个真正的(且独占的)应用程序。如果我们认为DDD和SOA共享共同的体系结构原则，但在许多其他方面却有所不同，那么DDD在EA学科中的位置是什么？

Answer 1

DDD和SOA很好地结合在一起。通常，服务边界与有界上下文相匹配。您使用SOA设计跨上下文通信，所有这些都可以工作。EA并没有深入探讨如何在内部开发您的“服务”，但是DDD在那里帮助了您。

Answer 2

对我来说，DDD最大的优点是它能让你在分析业务领域时做你的工作。

对域的良好理解从来不是坏事，当然，这种说法对于SOA也是正确的。更重要的是，如果您能够为大多数实体构建一个公共数据模型，这将提高互操作性，因为您将能够构建更多标准化的服务，因此您将避免数据映射和转换的需要。当您完成服务组合和/或编排时，公共类型往往成为必需的类型。因此，如果你提前投入更多的工作，那么当你的服务和库存到达治理的时候，你会有更轻松的时间。

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

Answer 3

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

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

就技术架构而言，没有提到如何实现服务(DDD或其他)。它只是强调他们的存在，他们的镇定和他们的边界。

领域驱动设计，涵盖了软件构件设计的“如何”。这正是书中所发生的事情。当叙事摇摆到设计模式时，诸如领域库存和实体抽象等主题就会出现在画面中。

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