3 回答
如果您查看您提供的链接中描述洋葱架构的图像，则 DDD 关注的是领域模型层。
Onion 是一种系统架构模式，而 DDD 是一种设计系统中对象子集的方法。两者可以彼此独立存在，因此两者都不是另一个的子集。如果您将它们一起使用 - 那么作为一个整体，使用 DDD 设计的部分将是整个系统的一个子集。
用一个（可能不好的）类比：洋葱是设计房屋的一种模式，而 DDD 是一种铣削作为房屋一部分的木材的方法。
在我看来——它们相互补充——但从非常不同的角度来看。
洋葱架构就是让域/业务逻辑独立于“劣质”事物，如数据访问、用户界面、服务等。洋葱架构并不真正关心你是如何创建你拥有的域的——它坚持保护它免受外部依赖.
领域驱动设计就是关于如何为领域建模以及如何称呼您的对象。这意味着每个域类应该与它在它所处理的业务域中所代表的内容（即物理/现实世界）有直接关系。因此，客户对象应该在代码中命名为客户——它应该与现实世界中的客户具有相同的规则（或尽可能接近）。
我认为两者在系统本身的“您如何设计以及您的整体理念是什么”方面彼此不同。
使用洋葱架构，全世界都围绕着您的数据存储。这意味着您不关心您如何“完成工作”，但您更关心“我希望完成工作”。显然，最佳实践（小方法、好的变量名，也许像 Sigleton 等一些设计模式等）在这个范围内仍然有意义，但更多的是代码本身，而不是整个应用程序概述。
另一方面，当我们谈论 DDD 时，我们谈论的是业务，当我们对架构做出决定时，我们总是有我们想要解决的业务模型。当我说决策时，我的意思是系统可能拥有的决策总数（从变量/类/函数名称，到我们放置部分代码的位置，以及在一天结束时我们如何谈论这个系统本身）。我们可以说 DDD 是业务模型的“编程抽象”）。但是，如果没有业务来解决，我们当然无法制作 DDD，例如我们无法在 Shazam 之类的程序上制作 DDD，但我们可以在 Facebook 或 Spotify 等程序上制作 DDD。
我的选择是您不能相互混合，而是这是第一个决定。