BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

文章:演进架构中的领域驱动设计

| 作者 Mat Wall 关注 1 他的粉丝 , Nik Silver 关注 0 他的粉丝 ,译者 王丽娟 关注 0 他的粉丝 发布于 2009年9月23日. 估计阅读时间: 2 分钟 | 都知道硅谷人工智能做的好,你知道 硅谷的运维技术 也值得参考吗?QCon上海带你探索其中的奥义

领域驱动设计能非常容易地应用于稳定领域,其中的关键活动适合开发人员对用户脑海中的内容进行记录和建模。但在领域本身不断变化和发展的情况下,领域驱动设计变得更具有挑战性。这在敏捷项目中很普遍,在业务本身试图演进的时候也会发生。本文中,Mat Wall和Nik Silver介绍了他们如何在反思和重建高流量的新闻站点guardian.co.uk这一为期两年的计划背景下利用了DDD。

本文中,Mat和Nik展示了如何确保在软件架构中反映最终用户演变的认知,以及如何实现该架构来保证以后的变化。他们提供了模型中重要项目过程、具体演进步骤的细节。顶层标题:

  1. 计划背景
  2. 从DDD开始
  3. 增量计划中的DDD过程
  4. 进化的领域模型
  5. 代码级别的演进
  6. 演进架构中DDD的一些教训
  7. 附录:具体示例

Nik Silver是Guardian News & Media软件开发总监。他于2003年在公司引入敏捷软件开发,负责软件开发、前端开发和质量保证。Nik偶尔会在blogs.guardian.co.uk/inside上写Guardian技术工作相关的内容,并在他自己的站点niksilver.com上写更宽泛的软件问题。

Matthew Wall是Guardian News & Media的软件架构师,深入研究敏捷环境下大型Web应用的开发。他目前最关心的是为guardian.co.uk开发下一代的Web平台。他在JAOO、ServerSide、QCon、XTech和OpenTech上做过关于此及相关主题的各种演讲。

详细内容,请阅读全文演进架构中的领域驱动设计

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

服务 by 张 永锋

领域模型当中的服务的确让人不好理解,就像本文里面所说的ArticleService的一样,是一个模糊的概念。在自己写代码的过程当中,也越来越体会到这一种模糊给自己 带来的诸多困惑,不过,“创建 ArticlePublishingService和ArticleDeletionService”这样的方式,的确是一个很清楚的办法。非常赞同。

Re: 服务 by King Tobato

服务从职责分配角度去理解就很简单了。publish an article 显然不应该是article的职责.

服务 by 叶 旭辉

可以理解作者将计算比赛结果的方法放置在FootballMatch的领域对象中,但是这样随之而来的问题是使用这些业务方法的开发人员将不知道或者很难分辨具体的业务处理方法到底在哪个类中,就好比文章中举的例子,会有ArticlePublishingService、ArticleDeletionService、FootballMatch等的业务类,还有可能更多。
一般我的简单做法是,还是保持实体(Page)的简单性,只提供getter和setter方法,而把其它的业务方法统一归到业务层对应的实体业务对象(PageService)中去,这样架构层次清晰,查找业务方法方便统一。

业务人员来主导创建领域模型 by 叶 旭辉

让业务人员来主导创建领域模型的做法很有意义,这样更能看清问题的本质是什么,而不是由技术主导来解决问题。

如何让业务接受这种方式是个问题 by Lau Richmond

业务人员不愿意参加进来就白搭了,毕竟对于他们来说,额外要学习uml相关的东西,他们肯跟着项目组一起搞么?

国内的企业应用开发基本都是这样 by 张 鹏

国内的企业应用开发基本都是这样一个渐进型过程,确实需要不断完善的领域模型。随着用户--也就是业务人员对系统的使用,会逐步产生出很多对该业务的需求,比如销售管理系统的领域模型。

Re: 服务 by gyb gyb


一般我的简单做法是,还是保持实体(Page)的简单性,只提供getter和setter方法,而把其它的业务方法统一归到业务层对应的实体业务对象(PageService)中去,这样架构层次清晰,查找业务方法方便统一。

晕,实体只剩getter和setter,业务逻辑全放到service,你这是典型的事务脚本,根本和DDD不沾边嘛。

Re: 服务 by Wang Chunshan


一般我的简单做法是,还是保持实体(Page)的简单性,只提供getter和setter方法,而把其它的业务方法统一归到业务层对应的实体业务对象(PageService)中去,这样架构层次清晰,查找业务方法方便统一。

晕,实体只剩getter和setter,业务逻辑全放到service,你这是典型的事务脚本,根本和DDD不沾边嘛。

嗯,两个反模式占全了:贫血模型、肥服务类

Re: 服务 by 邬 杰

为什么 “publish an article 显然不应该是article的职责”。
在Java的mail API中发送mail的方法就是定义在Mail类中

Re: 服务 by SEA 先生

虽然是很清淅,但是会不会使服务类爆涨,每个服务类只处理一种服务?

Re: 服务 by 刘 兆东

贫血模型+胖服务层,这个是业务脚本吧,和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通知我

11 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT