DDD并实现持久性

由于我正在重新构建遗留企业应用程序的某些核心组件，因此我第一次使用DDD（在.Net中）开始工作。DDD并实现持久性

我想澄清的是，我们如何在适当的DDD架构中实现持久性？

我意识到域本身是持久性的无知，应该使用“无处不在的语言”来设计，并且当然不会被迫进入本月的DAC甚至物理数据库的约束。

我正确地说，存储库接口存在于域程序集中，但存储库实现存在于持久层中吗？持久层包含对域层的引用，反之亦然？

从哪里调用我的实际存储库方法（CRUD）？

来源

2011-08-23 EkoostikMartin

我是正确的库接口住域组件内，但持久层中存在的库实现？持久层包含对域层的引用，从不反过来？

是的，这是一个非常好的方法。

从哪里调用我的实际存储库方法（CRUD）？

不用考虑CRUD术语可能是个好主意，因为它太过于以数据为中心，并且可能会导致您进入Generic Repository Trap。 Repository有助于管理domain objects的中期和生命末期。 Factories经常负责开始。请记住，从数据库中恢复对象时，从DDD角度来看它处于中等阶段。代码如下所示：

// beginning 
Customer preferredCustomer = CustomerFactory.CreatePreferred(); 
customersRepository.Add(preferredCustomer); 

// middle life 
IList<Customer> valuedCustomers = customersRepository.FindPrefered(); 

// end life 
customersRepository.Archive(customer);

您可以直接从您的应用程序调用此代码。这可能值得下载，并看着埃文的DDD Sample。 Unit of Work模式通常用于处理交易和抽象选择您的ORM。

来源

2011-08-23 23:42:09 Dmitry

我同意德米特里在这里所说的一切，为清楚起见，我唯一要补充的是我建议你的客户/ UI项目引用一个'Application Services'层，它调用域上的方法（域聚合或域服务）并从这里调用存储库。这样，所有的逻辑都包含在这个应用程序服务中，您可以轻松地更改/添加用户界面。 –

我只会在对应用程序有明显好处时才添加服务层，而不仅仅是为了它。服务层是一个额外的抽象层，在许多情况下你可以不用。 –

@RobinvanderKnaap，事实并非如此，在实际软件开发情况下，应用程序服务层始终是必需的。如果您将UI开发团队交给域图层，则可能a）不知道如何使用它，b）可能会滥用它。您需要明确界面可以使用您的业务API（域层）做什么。 –

查看有关该主题的什么Steve Bohlen has to say。演示代码可以在here找到。

我在演示文稿中发现了关于如何为存储库建模的信息。

来源

2011-08-23 16:33:51

非常好，绝对是我见过的最直接的DDD介绍。代码很好，因为它不像其他许多示例那样花哨的管道。不幸的是，对于事情的实际情况，我真的很想找到帮助。 – EkoostikMartin

我是正确的库接口住域组件内，但持久层中存在的库实现？持久层包含对域层的引用，从不反过来？

我不同意在这里，让我们假设一个系统由以下层组成：

表示层（赢表格，网页形式，asp.net MVC，WPF，PHP，QT，JAVA， ios，android等。）
业务层（有时被称为经理或服务，逻辑放在这里）
资源访问层（手动或ORM）
资源/存储（RDBMS的NoSQL等）

假设这里是你越高，图层越不稳定（呈现最高，呈现最低，资源/存储最低）。正因为如此，您不希望资源访问层引用业务层，这是相反的方式！业务层引用资源访问层，您称DOWN不UP！

您将接口/合同放在它们自己的程序集中，而它们在业务层中完全没有用处。

来源

2018-01-25 22:11:48 Alex

DDD并实现持久性

回答

相关问题