从数据驱动开发到领域驱动设计的经验

Julie Lerman 对于领域驱动设计（DDD）深感着迷并且倍受启发，但在数据驱动开发方面的长期经历，使她在理解如何在 DDD 中使用自己技能的道路上，不断的挣扎、争论又满腹辛酸。Julie 自 2003 年起成为微软MVP ，作为顾问和导师从事.NET 平台方面的工作。她认为，或许由许多开发者都遭受了同样的痛苦，因此在MSDN 杂志上撰写了三篇文章来分享她所学到的经验教训。

Julie 强调，DDD 适用于复杂行为——并不是应用的每个部分都会包含这样的问题。对于应用中仅仅涉及简单的创建、读取、更新和删除（CRUD）的部分，我们或许最好采用非 DDD 的实现方式，但对于复杂行为和 CRUD 的结合部分，Julie 建议识别出复杂部分，并将其分解为独立的有界上下文，并对它们运用 DDD。

当进入 DDD 并对某个领域建模的时候，Julie 会聚焦于业务，研究所需的任务和行为。数据持久性与业务问题无关，因此它应该扮演支持的角色，而不是去干预领域设计。

Julie 遇到的那些麻烦中的一个主题，是在子系统之间分享类型和数据。在她看来，分享类型一直是强制性的，对同一个数据库中的相同表进行操作也是如此。DDD 让她学到，不分享某个领域模型也可能是完全没问题的，因此可以将来自不同子系统的数据的相同类型，存储在不同的表和数据库中。复制数据并不是一种过错，从长期来看，由于移除了分享数据的复杂性，这或许会简化我们的系统。

在她最后一部分分享中，Julie 讨论了一些使用 ORM 工具的过程中出现的问题——她使用的是实体框架。其中一个问题是单向关系，这是使用DDD 时的首选关联方式。最初的 DDD 书籍作者 Eric Evans 的建议是，“尽可能地约束关系是非常重要的”。对 Julie 来说，自打开始使用实体框架以来，双向关系一直是一项规范。然而现在她发觉，尽管双向关系很方便，但在领域中鲜有实际需求，而省去双向关系将会移除关系管理中的部分复杂性。

Julie 的文章还给出了一段用 C#和实体框架（微软用于.NET 平台的对象关系映射工具）编写的例子。

查看英文原文： Experiences Going From Data-Driven Development to Domain-Driven Design