DDD 数据库优先。如何处理聚合答案

【问题标题】：DDD Database first . How to handle aggregatesDDD 数据库优先。如何处理聚合
【发布时间】：2012-08-29 12:23:37
【问题描述】：

我正在尝试学习 DDD 的概念。我做了一个项目，我使用数据库优先方法。在基础架构中，我添加了一个 edmx 文件，我选择自动生成实体。现在在“域”中，我正在尝试创建聚合。

但是在这里我遇到了一些问题。我正在尝试创建一个名为“用户”的聚合，但用户已经存在于 ef 自动生成的实体中。我是否应该将聚合“用户”重命名为其他名称，并且在从数据库中获取数据时将其从数据库实体映射到聚合。

我做错了吗？或者我不应该自动生成实体还是实体聚合？

请提供建议和帮助。

【问题讨论】：

我不相信 DDD 在你的情况下工作（如果有的话）。您还没有将模型与基础架构分开。 1.您的实体不在您的域中，它们存在于基础架构中（坏）。 2. 您的模型基于数据库模式，而不是他们试图建模的模型（错误）。 3. 您的模型完全与 EF 绑定，而不是与基础架构无关（不好）。
如果我将实体移动到“域”，我可以将它们用作聚合。但我的模型与我的数据库模式完全相同。也许 DDD 是我的项目的错误方式。
不太了解实体框架，但“DDD 数据库优先”听起来有点矛盾。你不能先写代码吗？
问题是数据库设计已经完成了。我们花了很长时间才想出它。也许我们应该跳过 DDD 而只使用 EF。我们尝试构建的是一个大型 WCF 服务。

【解决方案1】：

如果您想忠实于 DDD，您应该将您的域对象建模为独立于您的持久性解决方案。 DDD 通过存储库处理持久性。不要使用 EF 生成的“实体”作为您的域模型；而是设计您自己的模型并实现一个使用 EF 进行持久性的存储库。

【讨论】：

【解决方案2】：

在我看来，领域驱动设计和“数据库优先”是对立的。领域驱动设计侧重于复杂行为，而数据模型侧重于数据的静态结构。

如果我有幸从一个干净的环境开始，我不会通过首先创建一个遗留数据库来让它变得比必要的更复杂。考虑到 DDD 面向复杂领域，其中发现和学习是过程的一部分。

为了支持持续的学习过程，最好依靠专为进化而设计的软件组件（例如可以在廉价单元测试下进行的面向对象的领域模型），而不是进化成本肯定更高的数据库设计.

没有人能在一开始就做好一切。所以我最好从一次性成本很低的东西开始。

【讨论】：