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

  • Jan Stenberg
  • 李彬

2013 年 10 月 18 日

话题:语言 & 开发架构

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

语言 & 开发架构