BT

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

文章:领域驱动设计和开发实战

| 作者 Srini Penchikala 关注 34 他的粉丝 ,译者 王丽娟 关注 0 他的粉丝 发布于 2009年2月5日. 估计阅读时间: 2 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

领域驱动设计(DDD)的中心内容是如何将业务领域概念映射到软件工件中。大部分关于此主题的著作和文章都以Eric Evans的书《领域驱动设计》为基础,主要从概念和设计的角度探讨领域建模和设计情况。这些著作讨论实体、值对象、服务等DDD的主要内容,或者谈论通用语言、界定的上下文(Bounded Context)和防护层(Anti-Corruption Layer)这些的概念。

本文旨在从实践的角度探讨领域建模和设计,涉及如何着手处理领域模型并实际地实现它。我们将着眼于技术主管和架构师在实现过程中能用到的指导方针、最佳实践、框架及工具。领域驱动设计和开发也受一些架构、设计、实现方面的影响,比如:

  • 业务规则
  • 持久化
  • 缓存
  • 事务管理
  • 安全
  • 代码生成
  • 测试驱动开发
  • 重构

本文讨论这些不同的因素在项目实施的整个生命周期中怎样对其产生影响,还有架构师在实现成功的DDD中应该去寻求什么。我会先列出领域模型应该具备的典型特征,以及何时在企业中使用领域模型(相对于根本不使用领域模型,或使用贫血的领域模型来说)。

文章包括一个贷款处理示例应用,来演示如何将设计立场、以及这里讨论的开发最佳实践,应用在真实的领域驱动开发项目之中。示例应用用了一些框架去实现贷款 处理领域模型,比如Spring、Dozer、Spring Security、JAXB、Arid POJOs和Spring Dynamic Modules。示例代码用Java编写,但对大多数开发人员来说,不论语言背景如何,代码都是很容易理解的。

详细内容,请阅读全文领域驱动设计和开发实战

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

读后感 by Kevin Nick

好文章 长见识

Re: 读后感 by jiuwu liu

看完了,文章是写的很好。我只针对测试代码发表一下我的意见:

public class LoanDomainTest {

@Autowired
1.private Loan loan;

@Test
public void testAddUpdateDeleteLoan() {

long loanId = 100;

// Add a new loan
Loan newLoan = new Loan();
newLoan.setLoanId(loanId);
newLoan.setLoanAmount(new BigDecimal("450000"));
newLoan.setLoanStatus("REQUESTED");
newLoan.setProductGroup("FIXED");
newLoan.setProductId(1234);
newLoan.setPurchasePrice(new BigDecimal("500000"));
2.loan.add(newLoan);
}

}

上面加粗的地方,看着很别扭,和将CRUD等业务方法放到Service层做法不同的是,只是将CRUD等业务方法放到了领域模型中(实体对象),所以现在CRUD时等先实例化一个对象来放数据,另外注入一个同样的对象来操作数据。

2处要是支持静态方法写成Load.add(newLoan)是不是更好?只是这样无法注入DAO对象。除了运用到注解来实现注入及持久化外,以及面向对象的分析外(即不是从数据库的角度来设计),没发现和现有的三层架构有多大的区别?大家来讨论一下?

奥拉拉 by Wang Chunshan

《重构与模式》,Martin Fowler著,Addison-Wesley出版社

Re: 奥拉拉 by Wang Chunshan

作者错了吧?

Re: 奥拉拉 by 王 丽娟

已修改,谢谢指正!

不纯粹的DDD by tsai samuel

示例代码中的领域对象,带有JPA的annotation,似乎不妥。难道领域对象就一定要存储到数据库,或仅限于用JPA来持久化吗?领域对象和特定实现技术耦合在一起,本身就是反模式。

Re: 不纯粹的DDD by Heath Glad

除了annotation,我觉得不应该把CRUD放到领域模型,尽管它注入了Repository.模型只应该处理跟领域有有关的逻辑.如果pojo不是运行在ejb这种容器里,repository恐怕就是一个大麻烦了,因为你每次使用模型,都要把repository显示的注入进来,但是,作者也说了,模型对外部技术的依赖应该尽量小.

Re: 不纯粹的DDD by zhang jason

示例工程中所依赖的jar包可以从哪打包下载?要自己一个一个找吗?

关于查询出List的对象。 by 刘 森

对于把CRUD放到领域对象中去我是支持的,但要一次要查询出一个List对象的数据.
请问这个查询方法应该怎样写呢??

Re: 关于查询出List的对象。 by zhang jason

示例应用的代码好象不完整。并且文中提出最好在服务层管理事务,但代码中却在BorrowerRepositoryJpaImpl这样的类中打了@Transactional标记?是我没看懂吗?

不错 by Tang JiJun

好文章,终于找到实践DDD的好文章了。。。学习中

Re: 关于查询出List的对象。 by Wang Yanjun

示例应用的代码好象不完整。并且文中提出最好在服务层管理事务,但代码中却在BorrowerRepositoryJpaImpl这样的类中打了@Transactional标记?是我没看懂吗?


我也没看懂,文章写的不错,可是代码好像和文章有很多不一致的地方,费解......

Re: 不错 by 刘 森

不错!1小时没有浪费 by fanfree fan

不错!1小时没有浪费

考虑成本了吗? by 周 祖林

感觉不错,实现用到的一些框架比较多,感觉这样成本将会很高

开眼界了 by chen tao

里面有这么多好的实践,光是看我就很心动了!
不管怎么说还有是有很多的东西没有接触过,努力啦!

Re: 关于查询出List的对象。 by 帮 马

把CRUD放入领域对象就是DDD了???

重构用DDD,需求经常变更的项目少用 by zheng spell

现在用DDD貌似还不靠谱吧,有谁的项目中用这个的吗?谁用谁找罪受,完全是忽悠人的把戏而已!用一种缺陷代替另外一种缺陷有意义不?要独立思考,不要被概念玩死了。

所谓的领域设计,是要对某个专业的领域有很深刻的认识,然后进行提炼和设计,才可以动手这样干的,个人认为领域设计更适合用来做项目的重构工作,现在项目需求经常变更,你可能连业务需求都没有完全搞清楚,就去玩DDD,不死才怪,等着被老板狂批吧!

Re: 重构用DDD,需求经常变更的项目少用 by liang tang

终于见到有人批判DDD了!个人也觉得DDD是一个把简单问题复杂话的典型。领域 - 驱动 - 设计不说大家也明白,EV无法是把他模型化,做了一个实现的分层构架,这反倒把DDD限制了。实际项目中最难的部分是抽取业务逻辑(即领域),采用何种层次结构和DDD完全无关!但作者几乎没提如何做真正的“领域驱动”,而是一味的推销它的所谓的DDD分层构架!

Re: 重构用DDD,需求经常变更的项目少用 by baoguo ding

赞同你的观点,我认为,做产品可以考虑用DDD, 做项目就算了吧....

感觉要做到真正的DDD其实很难 by chow jason

这个实例我看了,确实是DDD的一种尝试和努力,可我觉得这还是在“活动记录”和“领域模型”之间的状态,当然能满足实际需求就是有实际意义的。

读后感 by shi andy

进行DDD的时候,应该先找领域对象呢?还是先考虑其他的呢?是不是应该先分析问题域的领域对象,然后从领域对象延伸到其他方面呢??

关于DDD的一点感想 by Guo Eidson

正在项目中尝试使用DDD,感觉DDD的核心应该和敏捷开发有关,响应变化以及迭代演进。DDD在这方面提供了一个很好的指导思想,只是实践起来问题还很多,需要一点点去解决和完善。

Re: 考虑成本了吗? by 卫 威

作者讲述的是一种模式,这种方式让我们思考,基于的原则就是低内聚高耦合,将领域模型完全分离开,让我们更加关注领域而减少其他应用层和基础设施层得干扰,职责纯粹单一。

Re: 读后感 by du robet

DDD通过领域模型主要解决了需求、设计、代码的迭代,这个是在项目中采用OO技术以来,一直很难解决的问题,他不仅对产品,同时对项目的开发也是适应的。特别是需要长期维护的项目,其维护和功能扩展成本会大幅降低。

Re: 不纯粹的DDD by 帮 马

看了一下源码。
在service中注入领域对象也有问题,service是单例的,而领域对象是多例的,这样运行时就有多线程安全问题,用户A有可能看到、操作其他用户的数据,岂不是乱套了。

Re: 不纯粹的DDD by 曹 力文

这个源码有几个纠结的地方。
1、Do怎么能自己保存自己呢?怎么能依赖 Repository 呢?
2、service中怎么注入Do呢? service 不是领域服务层。是无状态的啊。

感觉前面讲的还可以,后面的实例实在有点误导。

Re: 不纯粹的DDD by shiwei chen

这个源码有几个纠结的地方。
1、Do怎么能自己保存自己呢?怎么能依赖 Repository 呢?
2、service中怎么注入Do呢? service 不是领域服务层。是无状态的啊。

感觉前面讲的还可以,后面的实例实在有点误导。

service 是无状态的没错~ 但是DO对象本身是不具备存储数据功能的,它只不过是调用数据库操作而已,这里的存储数据跟存储数据到数据库 是两个概念。

Re: 不纯粹的DDD by shiwei chen

service因为是无状态的,只是执行操作而已,无存储数据属性,不保存数据,天生就是线程安全的,怎么会乱套?

Re: 重构用DDD,需求经常变更的项目少用 by 文轩 杨

现在用DDD貌似还不靠谱吧,有谁的项目中用这个的吗?谁用谁找罪受,完全是忽悠人的把戏而已!用一种缺陷代替另外一种缺陷有意义不?要独立思考,不要被概念玩死了。

所谓的领域设计,是要对某个专业的领域有很深刻的认识,然后进行提炼和设计,才可以动手这样干的,个人认为领域设计更适合用来做项目的重构工作,现在项目需求经常变更,你可能连业务需求都没有完全搞清楚,就去玩DDD,不死才怪,等着被老板狂批吧!
在有复杂的业务逻辑项目中,为了更好的对应需求变更,才需要使用DDD啊

插件化开源开发平台JXADF by soft wmz

插件化开源开发平台JXADF,在模块化、插件化方面做得相当优秀,osgia.com中还有在线演示

DDD是驱动桥接业务与架构,但不一定决定物理架构 by 王 根

DDD能给我们指导领域方向,领域建模,如何围绕领域对我们的系统进行概念架构,它对我们的业务桥接过程还是很有帮助作用的,领域建模反应了系统业务方向,把握业务模型,在这样的指导下的架构才是符合需求的系统。
但是实际的物理架构严格遵循DDD编程模式未必是好事,或适当的架构形势,例如我们大多现实业务是对模型(Model)的业务操作逻辑,大多涉及的是Model的转换、传输然后持久化,若这些逻辑放在领域模型中,并不显得很合适,因为这样导致模型太充血,尽管违背了领域模型的模型强化原则,但是像持久化这种的逻辑也放在Model里面个人觉得不能接受,从可维护,可读行来说,我更喜欢它是纯粹的Model,而有一个Service(行为)驱动这个Model
DDD是很不错的概念,但是能在我们的业务系统中能完善的驾驭还需探索与更多的经验实践,而且也不能为概念是从,适合才是最好的,当然包括适合用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通知我

32 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT