我越来越了解领域驱动设计，并且对Naked Objects Pattern和Onion Architecture如何相互关联有点困惑？
单独地说它们与DDD的关系非常清楚，但它们是否也可以将它们相互联系起来？
答案 0 :(得分：3)
（感兴趣的声明：我是Naked Objects架构模式的作者，并管理Naked Objects Framework - NOF。）
我并不自信地了解洋葱建筑，但在某种程度上，这些想法似乎与Naked Objects兼容;在另一个层面上，它将苹果与橙子进行比较。
洋葱架构是一组设计原则，您可以在使用各种技术和模式从头开始构建架构时应用这些原则。 理论上，Naked Objects也是如此;实际上，你只能通过使用实现它的框架构建系统来采用Naked Objects模式 - 编写自己的系统太辛苦了。 Naked Objects Framework是最大，最纯粹的框架，但不是唯一的框架。
因此，有意义的比较不是在洋葱原则和NO 原则之间，而是在前者和NO原则的具体实现之间。显然，我会以NOF为例。
NOF非常强有力地实施和执行Onion所源自的原则：非常强烈的关注点分离。域模型几乎完全独立于基础架构：唯一的接触点是通过一个非常轻量级的接口（IDomainObjectContainer），它定义了一个服务，其实现被自动注入到任何想要它的域实体或服务中。比Onion架构更强大，您的UI对域模型具有零依赖性 - 因为它是通用的。 （除非您开始自定义UI，否则您可能会失去NO模式的好处）。
Onion的原则可以在域模型中进一步应用 - 确保所有域服务，例如，仅由接口定义和使用。我看到有些人试图让域对象之间的所有交互只通过接口，但是我从来没有看到它可以在任何规模上工作并且看不到它的价值。您可能希望阅读“群集”＃39;模式，这是一种将非常大的复杂域模型分解为具有严格依赖关系层次的独立集群的模式。这种模式并不依赖于NO，但在实践中，如果你没有获得NO的好处，那么采用它就没什么意义。
在这里，我来到我的主要观点，并且首先导致了NO模式的定义。在整个架构中采用严格的原则来分离关注点非常好。但除非您能够从域对象模型自动100％导出持久层和表示层，否则最终会失去关注点分离的大部分优势，因为对域模型的任何更改都意味着对其他层的更改，如果不是直接间接则间接更改。现代ORM在域模型到持久层映射方面做得很好; Naked Objects为域模型做了UI层。
简而言之，如果您采用坚定致力于NO原则的框架，您将获得洋葱所声称的好处。如果你的愿望或需要是建立你自己的架构，并且你想采用洋葱原则，那么这很好，但是不值得尝试弄清楚如何以某种方式将任何NO原则改造为自定义架构：这将非常困难，你可能不会看到任何好处。