BT

你的观点很重要! 快来参与InfoQ调研吧!

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

| 作者 Jan Stenberg 关注 9 他的粉丝 ,译者 李彬 关注 0 他的粉丝 发布于 2013年10月18日. 估计阅读时间: 2 分钟 | ArchSummit社交架构图谱:Facebook、Snapchat、Tumblr等背后的核心技术

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

DDD适用于复杂行为 by Wong Peter

对于应用中仅仅涉及简单的创建、读取、更新和删除(CRUD)的部分,我们或许最好采用非DDD的实现方式,对于复杂行为和CRUD的结合部分,识别出复杂部分,并将其分解为独立的有界上下文,对它们运用DDD。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT