在文献（博客，文章，对企业架构......书），似乎有SOA的EA真实的（和排他性）设备。如果我们考虑DDD和SOA有着共同的架构原则，但不同的许多人一样，什么是在EA纪律DDD的地方吗？
DDD和SOA发挥得很好。通常服务边界配合您的限界上下文。您可以使用SOA，它的所有作品设计跨情境的沟通。 EA并没有深入到如何开发您的“服务”内，但DDD帮助你。
对我来说，DDD的最大优点是，它让你做你的工作分析的业务领域时。
域的良好的理解从来都不是一件坏事，当然这种说法适用于SOA也是如此。更有甚者，如果你设法建立最实体的通用数据模型，这提高互操作性，因为你将能够建立更规范的服务，所以你将避免数据映射和转换的需要。当你做服务组合和/或编排常见类型往往成为一绝。所以，如果你把更多的工作前期，你将有更容易的时间后，当你的服务和存货得到治理。
正如阿列克谢已经说过，DDD和SOA不干预和很好地协同工作。
在他的书中，SOA设计模式，托马斯·尔介绍软件如何最终被由和居住在这可能是技术，相关平台或资源的建筑元素。他接着解释了面向服务的技术架构的重要性和它的四种常见类型，其中有：
为了尽可能的技术架构而言，没有提供的服务应该如何实现（DDD或其他方式）提。它只是强调他们的存在，他们的组合性和它们的边界。
领域驱动设计，涵盖了“如何做”的软件组件设计。这就是这本书究竟发生了什么。当旁白摆动设计模式，主题如Domain库存和实体抽象进入画面。
因此，只要设计方法符合到SOA的四个特点（业务驱动，厂商中立的，企业为中心，组成中心），它的设计原则（标准化服务契约，服务松耦合，服务抽象，服务的可重用性，服务自治，服务无国籍，发现性服务和服务组合性），这在我看来DDD使用时，它可以安全地用于设计和实施一个软件，它提供的服务。
DDD，作为一个EA大师（我相信这是加里Booch的）曾经说过，是由DDD作者（在他的DDD书EA的误解的结果，他混合了从概念，逻辑，物理实现的概念，经营观念 - 一个非常，非常危险的事情）！
基本上，当你谈论EA，你必须总是不同的观点之间的辨别（借用的Zachman EA框架术语），你是在EA开发过程的一个特定阶段有关与特定观点的边界内的结构模型。例如。
标识（类型）------范围--------规划师的看法----行我ZF
定义（业务）----- ------概念性感知业主-----------行II ZF
代表（系统）---- LOGICAL ---------建筑师感知-------行III ZF
指定（技术） - 物理--------工程师感知--------行IV ZF
配置（工具）-----实现 - 分包商的看法 - 行V ZF
清单（操作）-INSTANTIATION ---操作感觉--------行VI ZF
换句话说，DDD笔者理解错了，他混了苹果和桔子。基本上，早在当他写的书DDD 2000年代初，他不熟悉EA研究（Zachman框架的第一个版本发表于80年代末，但它并没有与企业界的增殖相当长的一段时间）。