领域驱动设计DDD应用心得

09-07-30 banq
Domain Driven Design applied

http://blog.jteam.nl/2009/07/28/domain-driven-design-applied/

作者以给 Osix做的一个无线移动支付系统为例子,谈谈自己DDD实践的心得:

DDD 最重要的两个概念是:

1.无所不在的语言,这个语言将所有角色都包括进来,领域专家、开发者等利益相关者,这个语言是每个人都使用,就无需翻译,就不会所谓信息传递的拷贝走样原理,因为语言只包含名词和动词,这就意味着你可以完成 Rich Domain Model。

2.使每件事情明确,类之间关系要明确,并且取名,在OO设计中,取名是一个非常重要的步骤,简单的名词就击中事物本质。

作者起初给一个对象取名为LogEntry,后来咨询领域专家,认为取internet session 比较好。

作者认为富模型是DDD实施后的逻辑结果Rich Domain Model is the logical consequence of a DDD project。

另外一个极端是put all logic in the domain将所有逻辑都放入领域,这就不叫建模了,使用模型概念就是让一些东西划出你的领域范围之外,因为它们要么是不相关或不切合实际的实现。

[该贴被banq于2009-07-30 14:50修改过]

xmuzyu
2009-07-30 22:08
我也说一点我个人的心得,我觉得领域驱动设计主要包含一种思想,它是针对于某个具体的领域的,经过领域建模后形成的模型(当然目前来说最成熟的是对象模型)是符合这个领域,并且要想实现一个好的领域模型要求设计人员和领域专家很好的配合,如果对某个领域不够了解,也是很难得出好的领域模型出来,并且这个模型的形成也许要一个公司或者个人在某个领域的沉淀来形成,经过积累沉淀后的领域模型能更加符合领域的实质。

不过目前国内很少有公司真正用到了领域模型,很多因素在里面,公司有自己的开发规范和流程,如果用公司的流程和规范进行开发,公司可以很好的进行项目管理,可以估算项目在多长时间完成,需要投入多少,这些都是一个公司长期积累形成的,想改变很难。比如目前我所在的公司,在银行系统方面,可以说全国是数一数二的公司,但是内部的开发可以说根本没有对象模型,也没有代码复用。

bloodrate
2009-07-31 14:29
请问谁能站出来充当领域专家?

banq
2009-07-31 14:31
>请问谁能站出来充当领域专家?

以前做个此类领域项目的失败者。哈哈 中国特色

bloodrate
2009-07-31 14:45
如果你找客户作领域专家,有个问题就在于,中国的客户,尤其是政府客户,绝对说不出来“EntityLog”应该被称作“InternetSession”这样的建议,统一语言建立不起来;如果找第三方咨询机构作,你和领域专家之间的统一语言建立起来了,咨询机构和客户之间还要维护语言的专义,相当于还是没建立起来,尴尬阿。

xmuzyu
2009-07-31 16:47
我们公司的主要业务是做银行方面的,在做项目的时候,我们部门专门有在银行有过15年工作经验的人员和我们进行沟通,我觉得他如果再懂一点IT方面的知识就可以算是领域专家,但是目前他也只是负责给我们介绍一些银行的业务流程以及一些概念性的东西。

bloodrate
2009-07-31 17:31
对啊,按照banq的例子,http://blog.jteam.nl/2009/07/28/domain-driven-design-applied/

一个在银行15年工作经验的人,能给你讲银行的流程没问题,但是怎么可能说的出领域模型“EntityLog”不能精确的代表业务,应该用更精确的“InternetSession”呢?

bloodrate
2009-07-31 22:33
还有个难点,文中自始至终强调“统一语言”的重要性,但是这并不好操作,比如你把你定义好的模型放在哪里?按照国内典型做法是列成表格放在文档里,并把其传给各个组员,可是效果是可想而知,文档有几个弊端

1、文档总是尽可能的详细,缺乏一目了然性,想了解领域模型必须认真的把文档看完

2、文档是记录手段,不是沟通手段,通过传递文档进行沟通是低效的,因为不是每个人都会认真看,不是每个人都意识到这个文档的重要性

所以很多专家认为领域模型应该写在白板上或者用n次贴贴在墙上,尽量简洁,让每个组员走动过程中都会无意间看到,这样形成一种视觉上的潜在印象,久而久之印在大脑里。

猜你喜欢