在.NET中应用领域驱动设计的最佳实践是什么？

Question

我一直在尝试学习和应用领域驱动设计概念到我的软件开发中。我尝试做的第一件事是基于业务逻辑需求创建我的领域模型。我通常还会使用OR Mapping工具，例如LLBLGen、NHibernate或Linq to SQL，创建数据模型和数据访问层。然而，领域模型和数据模型通常非常相似，这让我想知道维护两个模型真正带来了什么好处。

有人能分享一下他们对领域驱动设计的实际想法吗？此外，在应用DDD时，您将如何处理数据模型或数据访问层？

提前致谢。

编辑

发现一篇很好的文章，其中包含示例代码，介绍了仓储模式。

- weilin8

Answer 1

我通过仓储模式来抽象我的数据访问，因此使我的领域对象完全成为POCO，并且与数据提供程序无关。

这使我可以从领域的角度来构建我的应用程序，主要通过单元测试来集中处理逻辑。

一旦这个过程完成，我就会放入表现层（通常是网页），然后才会提交到具体的数据库架构。然后我实现我的具体仓储类，可以是L2S。

我在这里起草了几篇文章-http://www.duncangunn.me.uk/dasblog/2009/04/11/TheRepositoryPattern.aspx http://www.duncangunn.me.uk/dasblog/2009/06/27/MockingLinqToSQLRepositories.aspx

请保持关注，在接下来的几周中，我将记录并提供使用工作单元模式的实现的示例代码。

- Duncan

Answer 2

我们直接将领域对象映射到数据库，这意味着我们没有单独的数据访问层，而是将其视为基础设施代码。

我们大多使用Fluent NHibernate进行配置。

- Mike Chaliy

---

你是否遇到过数据模型与业务逻辑不完全匹配的情况？你是如何处理这些情况的呢？谢谢。 - weilin8

这要看情况。Fluent NHibernate 提供了一种覆盖自动推断配置的方式。这意味着你可以让 90% 的模型自动映射，然后手动为剩下的部分提供配置。但是，如果你的数据模型可能会大量不兼容（例如遗留系统或疯狂的数据库管理员），我认为最好有一个真正的数据访问层来作为抽象层。 - Mike Chaliy

Answer 3

“拆分有界上下文（Splitting bounded contexts）也是DDD的一个重要好处，您可以在各自的上下文中解决每个问题，即使必须在上下文之间复制数据。”

“良好的聚合根定义可以简化设计，并导致潜在的性能改进（通过网格计算实现可扩展性，请参见Gojko Adzic post）。 ”

“当您的设计真正成为领域驱动时，您的应用程序更容易适应新的业务需求，因为实现真正成为实现细节。”

- thinkbeforecoding