DDD 和“洋葱架构”有什么关系？
What is the relationship between Domain-driven design (DDD) and "The Onion Architecture" of Jeffrey Palermo?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
What is the relationship between Domain-driven design (DDD) and "The Onion Architecture" of Jeffrey Palermo?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（3）
在我看来，它们是相辅相成的，但视角却截然不同。
洋葱架构就是让域/业务逻辑独立于数据访问、UI、服务等“劣等”事物。洋葱架构并不真正关心你如何创建你拥有的域 - 它坚决保护它免受外部依赖。
领域驱动设计就是关于如何对领域进行建模以及如何称呼对象。这意味着每个域类应该与其所处理的业务域（即物理/现实世界）中所代表的内容有直接关系。因此，Customer 对象应该在代码中命名为 Customer - 它应该具有与现实世界中的 Customer 相同的规则（或尽可能接近）。
In my opinion - they complement each other - but from very different perspectives.
Onion Architecture is all about making the Domain/BusinessLogic independant on 'inferior' things like data-acccess, UI, services etc. The Onion Architecture doesn't really care how you made the domain you have - it's adamant about protecting it from outside dependencies.
Domain Driven Design is all about how you model your Domain and what you call your objects. Meaning that each Domain class should have a direct relation to what it represents in the business domain it is adressing (ie. the physical/real world). So a Customer object should be named a Customer in code - it should have the same rules as a Customer does in the real world (or as close as it is possible).
如果您查看您提供的链接中描述洋葱架构的图像，就会发现域模型层是 DDD 关注的重点。
Onion 是一种系统架构模式，而 DDD 是一种设计系统中对象子集的方法。两者可以独立存在，因此两者都不是对方的子集。如果您将它们一起使用 - 那么作为一个整体，使用 DDD 设计的部分将是整个系统的子集。
使用一个（可能不好的）类比：洋葱是设计房屋的一种模式，而 DDD 是一种铣削房屋一部分木材的方法。
If you look at the image that describes the onion architecture in the link you provided, the Domain Model layer is what DDD focuses on.
Onion is an architectural pattern for a system, whereas DDD is a way to design a subset of the objects in the system. The two can exist without eachother, so neither is a subset of the other. If you were to use them together - then as a whole the part that is designed using DDD would be a subset of the entire system.
To use a (probably bad) analogy: Onion is a pattern to design a house, and DDD is a way to mill the wood that is a part of the house.
我认为两者在系统本身的“如何设计以及总体理念是什么”上彼此不同。
借助洋葱架构，整个世界都围绕着您的数据存储。这意味着你不关心你如何“完成工作”，但你更关心“我想要完成工作”。显然，最佳实践（小方法，好的变量名，也许一些设计模式，如 Sigleton 等）在此视图范围内仍然有意义，但更多的是代码本身，而不是整个应用程序概述。
另一方面，当我们谈论 DDD 时，我们谈论的是业务，当我们做出有关架构的决定时，我们总是有我们想要解决的业务模型。当我说决策时，我指的是系统可能拥有的决策总数（从变量/类/函数名称，到我们放置部分代码的位置，以及最终我们如何谈论这个系统本身）。我们可以说 DDD 是业务模型的“编程抽象”）。当然，如果没有业务需要解决，我们就无法制作 DDD，例如，我们无法在 Shazam 这样的程序上制作 DDD，但我们可以在 Facebook 或 Spotify 等程序上制作 DDD。
我的选择是你们不能互相混合，但这是第一个决定。
I think the two differs each other on the "how you design and what is your overall philosophy" on the system itself.
With the onion architecture all the world is around your Data store. This means that you do not care on how you "do the job" but you care more on "i want the job done". Obviously best practises are (small methods, good variable names, maybe some design patterns like Sigleton etc. etc) are still have a meaning in this scope of view but more for the code itself and not so more for the whole application overview.
On the other hand when we talk about DDD we talk about Business and when we take a decision about the architecture we always have the Business model we want to solve on our minds. And when I say decision I mean the total from decisions a system may have (from Variable/Class/Function names, to where we place a part of code and at the end of the day how we talk about this system itself). We could say that a DDD is a "programming abstraction" of the Business Model). But of course we can not make DDD with out have a business to solve e.x we can not make DDD on a program like Shazam but we can make DDD on a program like Facebook or Spotify.
My option is that you can not mix each other but instead it's the first decision.