领域驱动设计

Question

DDD的分层方案表明这些层应该是;

演示/应用/域/基础结构

Evans书中的图表显示了访问基础架构层的Presentation。我对这个图的解释是否正确，因为任何上层都可以被允许访问任何较低层？

Answer 1

这个问题是用“图层”这个词提出来的，所以我最初的回答是针对图层的。最好开始说DDD不是关于刚性层，它是关于以易于测试和改变的方式构建应用程序，因为它鼓励分离不同对象之间的关注点。

我不喜欢将域称为“层”，因为域对象并不真正形成通常意义上的层，它们在层之间传递，但不属于任何层。至于让表示层访问基础设施，该图表示它是一个选项。由演示文稿抽象对基础架构的访问权限取决于您。在大多数情况下，我倾向于通过应用程序层以避免将其与实现细节联系起来，但直接方法是一种选择，决定取决于您。

我认为阅读埃文斯的书有点令人沮丧，因为缺乏具体的例子，但他试图使其广泛适用，而且有些语言比其他语言更灵活，所以他们可以做不同的事情。例如，当使用Java和Hibernate时，我没有从域到数据访问对象的任何引用，我认为Hibernate持久性集合实现就像允许对域模型进行惰性遍历一样服务于存储库。但这是基于我选择的语言和库的实施决策，其他情况可以证明不同的决定。

Answer 2

嗯，恕我直言DDD并不是关于'分层'。 它更多的是建立您正试图以一种好的方式解决的问题，以便您的模型（实体，价值对象，存储库，服务，规范）反映现实世界的问题域。

然而，你编写的类之间确实存在某种“分离”，但我真的不会把它称为“分层”，因为恕我直言，你的表示类和域类访问是完全可以的例如，基础设施。 但是，域类应该不依赖于表示类，但事实恰恰相反。

我主要以这种方式组织我的项目：

• a有一个包含演示相关内容的程序集。 （表格等......）
• 我有一个包含'domain'的程序集。这包括实体，存储库 - 接口，规范类等......
• 包含存储库实现的另一个程序集。
• 一组基础架构程序集：
  • 一个通用的'框架'dll，其中包含我可以在我的演示文稿，我的域类等中使用的工具......
  • 一个包含DB访问帮助程序的DLL（在我的例子中，是NHibernate周围的一个薄包装器）。

与Nathan Hughes所说的相反，我认为您的表示层可以访问基础架构，因为我有时会省略“应用程序服务层”。在这种情况下，我的表示层是我的应用程序。 我也使用NHibernate，对我来说，我的表示层可以访问NHibernate助手。因为，我的应用程序（在某些情况下是我的表示层）是唯一了解应用程序上下文的“事物”。所以那就是那个负责启动和提交交易的人。

（正如埃文斯所说 - 在第5章我认为：语境是王）。