在 .NET 中应用领域驱动设计的最佳实践？答案

【问题标题】：Best practice to apply domain driven design in .NET?在 .NET 中应用领域驱动设计的最佳实践？
【发布时间】：2010-11-14 20:59:28
【问题描述】：

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

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

提前致谢。

编辑

找到了一个很好的article，带有示例代码，关于存储库模式。

【问题讨论】：

标签： c# .net domain-driven-design

【解决方案1】：

我通过存储库模式抽象了我的数据访问，因此我的域对象完全与 POCO 和数据提供者无关。

这让我可以从领域的角度来塑造我的应用程序，专注于逻辑，主要是通过单元测试。

一旦解决了这个问题，我就放入了表示层（通常是网页），然后提交到具体的数据库模式。然后我实现了具体的 Repository 类，它可以是 L2S。

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

在接下来的几周内请密切注意，因为我将记录并提供我的实现的示例代码，它也使用了工作单元模式。

【讨论】：

【解决方案2】：

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

我们在大部分配置中使用Fluent NHibernate。

【讨论】：

您是否遇到过您的数据模型不完全符合您的业务逻辑需求的情况？你如何处理这些案件？谢谢。
这取决于。 Fluent NHibernate 提供了覆盖自动扣除配置的方法。意味着您可以自动映射 90% 的模式，然后为其余部分提供手动配置。但是，如果您的数据模型可能在很大程度上不兼容（例如遗留或疯狂的 dba），我认为最好让真正的数据访问层充当抽象层。

【解决方案3】：

拆分有界上下文也是 DDD 的一大好处，您可以在其上下文中解决每个问题，即使您必须在上下文之间复制数据。

良好的聚合根定义可提供更简单的设计并带来潜在的性能改进（通过网格计算实现可扩展性，请参阅Gojko Adzic post）。

当您的设计真正成为领域驱动时，您的应用程序将更加灵活地满足新的业务需求，因为实现真正成为实现细节。

【讨论】：