域对象和 EF 实体的 DDD 分离

Question

在最近从 EF4.0 升级到 EF5.0 和 Code First 的一些规则中，让域模型与 Code First 一起使用，我们的团队决定通过使持久对象的 POCO 代表 1 来分散我们的关注点1 这些持久 POCO 中的数据库列和关系的映射。为每个持久对象使用 FluentApi 配置，我们暂称这些“持久对象”。一些域对象利用抽象类、几个接口和业务规则的规范拆分成几个持久对象。由于 DDD 将域业务对象称为“实体”，我们发现这令人困惑，因为 EF 指的是实体。我们将 POCO 放在一个单独的库项目中。在我看来，它们开始看起来像 DAO。

鉴于以上是选择将域对象与 Code First 的可持久 POCO 合约分开？

我提出的反对意见是，这意味着持久对象将作为 WCF 数据服务对象公开。我停止了开发，直到我们有了一个小的工作版本（我们的核心对象可以推送到 5 个表和 3 个域对象）。我不想继续使用其他 70 多个 POCO，直到我确定这是最佳实践或更好的另一种更类似于 Eric 在蓝皮书中的大纲的方式。

Answer 1

我已经做到了，在单独的项目中拆分域实体和 EF 映射类。我也用 nhibernate 做到了这一点。 在基础设施相关项目中保留映射类。它了解你的坚持。

关于为 wcf 服务公开实体，我建议您使用应用层并使用数据传输对象模式公开数据。没有花哨的东西。只是让您更好地控制 wcf api 的粒度。通常域实体处于如此低的级别，它需要知识和多重调用来获取特定交互（用例）所需的数据。