对领域驱动设计的初步认识(九)

1.客观主体(例如“企业”)具有业务;
2.领域属于某个客观主体的具有一定边界的业务。
3.从领域抽象出模型。
上面应该是共识,但我感觉仍然有问题没有弄清楚。
1.客观主体和领域的关系?
2.客观主体和领域的对应关系:一对一或者一对多?
3.领域和模型的对应关系:一对一或者一对多?
4.究竟是领域相互独立还是模型相互独立?
5.是业务变更了,还是领域不稳定?
6.领域边界的稳定和模型的关系?
[该贴被flyzb于2010-12-16 21:57修改过]

我总结并反思了一下,谈一下我的答案。
  1.领域是具有一定边界的业务,这个边界是靠人来辨识的,所以领域是有一定主观色彩的客观存在。
  2.既然领域有边界,那么一个客观主体自然会有多个业务领域,它们是一对多的关系。
  3.我们常用知识来描述领域,这种知识分析抽象的结果就是模型。由于这种认识有其客观性,也有主观性,所以领域专家十分重要。我在企业里做软件往往要当半个领域专家,尤其是从信息化地角度看业务。领域和模型可能是一对多的,但应该尽量地少。
  4.按理说领域应该是相互独立,其对应的模型也相互对立,这是理想情况。可现实却不是这样,因为我们在做业务分析时往往由于自身对领域知识认识不够而根本就没有划分清楚。以jivejdon中Account对象为例,如果严格按照领域划分的话应该切成2个域:一个是纯粹的Account对象,不包含任何jive的信息,在企业里我们知道这属于HR的部分;另一个是AccountInJive,表示Account对象在Jive的专属信息。呵呵,banq,在这里我有点鸡蛋里挑骨头,因为这种情况在小项目里太多了,因为小项目里人们很难看清楚这点,也有因为是小项目而不愿意花费力气。另外banq在DDD的ppt里的那个订单和订单传送方式的例子也一直让我印象深刻。
  5.其实业务或者领域是否稳定不是关键,对我们最有意义的是如何保持模型的相对稳定,尽可能通过模型的可配置性或者组装性来适应业务的变化。应该说DDD已经给我们指出了一套比较好的建模技术,但还不够完善。对于目前DDD技术,我的感觉还是比较“刚性”,我尤其感觉DDD的聚合在形式上比较僵化。
  6.其实领域边界是稳定的,理想情况下业务变更了应该加入新的模型即可。然而由于我们往往对业务领域边界认识不清楚,所以“不是边界不稳定而是我们根本就没有分清楚边界”,比如上面的Account例子。领域边界的不清晰,导致模型边界不清晰,这样业务变化了,软件自然就扩展性不好。所以在我前面的帖子就提到,做好领域研究非常重要,甚至超过技术本身。就算是领域专家有很多也是伪专家,往往知其然而不知其所以然,同样一个业务在不同企业的表现也是不同的。SOA为什么难做,其实根本上不是技术层面的,而是业务领域层面的。
[该贴被flyzb于2010-12-16 23:29修改过]

你这么问,感觉这些熟悉的词一下子又变得陌生起来。有点不知道从哪里说起的感觉,先打个比方圆圆场。

一部电影 = 一种业务
这部电影的一个片段 = 这种业务的一个场景
这部电影的一个演员 = 参与这种业务的一个实体
这部电影的所有演员 = 参与这种业务的所有实体

“领域模型”这个词根据上下文不同,有时候是集合的概念,有时是个体的概念。为了避免产生误解或歧义,这里我用“实体”来承担表达个体概念的部分,这样说到“领域模型”时就是一个集合的概念了。

那么这个比喻中的领域是什么,答案是“电影”。这个电影不是表示具体某部电影的概念,表示的是“电影领域”的概念。

现在尝试回答flyzb的问题。

3) 领域与模型的关系?
这个问题就是在问“电影领域”与“演员”的关系?答案很明显,“电影领域”有很多个(种)“演员”,“领域”有很多个(种)“模型”。

4)领域是一个整体的概念,可以根据需要划分多个“子领域”,比如“武侠电影”、“科幻电影”,它们相对独立,但也可能结合(如“科幻武侠电影”),因为他们都是电影。“模型”是“演员”,演员之间相对独立。

5)“领域”是刻画的是“电影”共性,“业务”是具体的一部部“电影”。

6)随着“电影”(领域)的不断发展,需要新类型的“演员”(模型),反之,新类型的“演员”(模型),可能会发展“电影”(领域)。

第1、2问题,客观主体的主观认识即“模型”(演员),所以我理解为还是在问“模型”(演员)与“领域”(电影)的关系。
[该贴被jdon007于2010-12-16 23:15修改过]

To jdon007
这里不是玩文字游戏,而是基于我们的项目经验和遇到的问题结合DDD在做反思,希望你先去看看DDD,你至少先可以从infoq.com上下一个《领域驱动设计精简版》的pdf看看。

2010年12月16日 22:58 "flyzb"的内容
另外banq在DDD的ppt里 ...

是公开的 么?在哪儿可以下载?

呵呵,很久以前,我曾经用“向自然学习”作为自己的个性签名。这个与你有相似之处。不过感觉你在思考领域问题时,是半自然的状态,并没有抛开不必要的的经验与技术的制约。思考领域问题时,请忘记你是技术专家。“像外行一样思考,像专家一样实践”,个人以为这是一个值得采纳的建议。下面说说我对DDD本身内容的概述和个人的解释。

DDD的主要内容
1)“模型驱动设计”将模型表达为:服务、实体、值对象。领域是从分层架构中分离出来, 与各种界面无关。
2)聚合根作为根将相关实体和值对象组合起来形成一个整体。
3)实体和聚合根都在仓库中保存,可从仓库中获取。
4)实体、值对象、聚合根的生成都交给工厂来完成。

上述我对DDD本身的概述如果没有什么错的话,那么我现在使用隐喻的方式,将其形象化和具体化。

1)服务相当于剧本,实体相当于演员,值对象相当于道具。
2)聚合根相当于布景,将相关演员与道具组织在一块。建模时先有实体、值对象,后才有聚合根,因为聚合根不过提供相关实体与值对象聚合的场所。
3) 仓库相当于剧组。演员、道具、布景一旦进入剧组,就可以从剧组中获取了。
4)工厂相当于电影学校和布景、道具厂商。

领域建模就是要拍一部电影,按照领域的语言和思维来拍一部电影。为啥拍这电影,因为有市场,有用户需求,即有业务。

我们知道拍一部电影最为关键的元素是:剧本与演员。所以我讨论时忽略其他的元素,主要说剧本与演员,即场景与模型。

那么从分层架构分离领域剩下的界面是什么?界面是用来看这部电影的,可以使用ppstream,可以使用pplive等等,这些都可以用来看“电影”,即使用“领域模型”的界面。

我不知道我上面的解释,能否清晰地表达我对“领域”、“领域建模”的理解?如果你可以理解为,也就理解我上面的分析了,这不是玩文字游戏,这是将领域建模,回归生活,回归自然。

按照你的建议,DDD这本书,我周末会花点时间通读一下。

2010年12月17日 09:55 "jdon007"的内容
2)聚合根作为根将相关实体和值对象组合起来形成一个整体。
3)实体和聚合根都在仓库中保存,可从仓库中获取。
4)实体、值对象、聚合根的生成都交给工厂来完成。 ...

这几点在使用框架技术条件下,怎么实践呢?我估计你没有这么实践吧?

2010年12月17日 10:22 "xuzhh"的内容
这几点在使用框架技术条件下,怎么实践呢?我估计你没有这么实践吧? ...

2) 对象的组合,可使用结构型模式。
3)仓库相当于缓存,可使用缓存技术。
4)对象的创建,可使用工厂模式。

晕,兄弟!你所说的框架技术,这已经涉及到具体拍电影的各种技术实现了,“写剧本、找演员”时也要考虑这些吗?

2010年12月17日 10:50 "jdon007"的内容
晕,兄弟!你所说的框架技术,这已经涉及到具体拍电影的各种技术实现了, ...

昏,建模和实现总要一致,如果和实现分离了,模型就没有生命力了。

2010年12月17日 09:55 "jdon007"的内容
1)服务相当于剧本,实体相当于演员,值对象相当于道具。
2)聚合根相当于布景,将相关演员与道具组织在一块。建模时先有实体、值对象,后才有聚合根,因为聚合根不过提供相关实体与值对象聚合的场所。
3) 仓库相当于剧组。演员、道具、布景一旦进 ...

呵呵。。。你打的比喻完全就和DDD不着边。其实我只是想指出一种学习的态度,“不要人云亦云”。我们应该学会逆向思考:
1.服务是什么?自己在过去的项目中用过服务吗?如果不用,会怎么样?如果用了,用好了吗,出现了DDD指出的问题吗?
2.聚合是什么?为什么要用聚合?自己用过聚合吗?DDD的聚合采取的形式是什么?除了DDD中的聚合,还有别的聚合吗?
  对DDD其他的要素可以以此类推。其实DDD不太适合初学者和小项目,DDD是经历过很多项目的失败和成功才总结出来的。所以我是反对把DDD当成一种理论学习的,在实战中不懂得东西不要乱用,但是一定要感悟,也就是说你可以先不去用DDD,但可以在实践中感悟DDD的思想和要素,然后明悟真伪。所以我发了这么多帖子,希望大家从自己的实战去印证,共鸣。这里不是没事无聊的闲谈,而是基于实践的关于DDD的灵魂的交流。
[该贴被flyzb于2010-12-17 11:00修改过]

2010年12月17日 10:59 "flyzb"的内容
DDD是经历过很多项目的失败和成功才总结出来的。 ...

Martin Fowler在《领域驱动设计》作序说;“希望本书是一本非常有影响力的书籍,....... Eric最值得我尊敬的一个方面是他敢于讨论还未取得成功的事情”。

2010年12月17日 11:15 "jdon007"的内容
2010年12月17日 10:59 "flyzb"的言论
DDD是经历过很多项目的失败和成功才总结出来的。 ...


Martin Fowler在《领域驱动设计》作序说;“希望本书是一本非常有影响力的书籍,....... Eri ...


  我简直无语了。。。我们应该去如何学习一门理论,如何应用一门理论?
  DDD是对一些复杂IT项目成功要素的总结而形成的一种理论。正确地理解DDD是关键,只要成功运用DDD的思想和要素就可以了,绝不是照搬。就算没见过DDD,也可能在实践中运用过DDD的思想和要素。

[该贴被flyzb于2010-12-17 12:20修改过]

2010年12月17日 12:19 "flyzb"的内容
DDD的思想和要素。 ...

是什么呢?

2010年12月17日 12:29 "xuzhh"的内容
2010年12月17日 12:19 "flyzb"的言论
DDD的思想和要素。 ...


是什么呢? ...


你可以从我发的第一个帖子看起,看完就明白了。

相对你十年的技术生涯,我确实一个新初茅庐的新手。但是

1)“术业有专,闻道有先后”而已。我第一次听人评价我“人云亦云”,以前常听见的评价是我“不合群”。反思,不是反着思考,是反复思考,反复思考后可能会出现逆向的情景,这是自然而然产生的现象,不是一开始就逆向思考。

2) 我阅读的资料来源一般有两种:a)官方资料 b)原创者。比如对DCI、MVC就是从Trygve Reenskaug那里得来,相对他来说,你也是一个新手,因为他有五十年的工业强度的经验,比如REST就是从Roy Thomas Fielding那里,他是真正的实践与理论专家,比如对xmmp协议的模型认识就是从rfc最权威的文档得来,诸如等等。如果是技术实现,则更多地参考官方的文档和例子。

3)DDD就是对从分层架构架构分离出来的模型进行独立、系统的思考。这个思路其实并不新鲜,MVC也是将M-VC分开,M就是模型,VC代表界面。在我理解了DCI、MVC后,我甚至觉得没有必要再看DDD了。因为MVC与DCI已经包含了DDD的思想,甚至超越了DDD,因为Trygve Reenskaug关注的是现实世界(用户心中的模型)与代码(程序员心中的模型)之间的直接映射,用可读性极高的代码呈现实的世界。

4)DDD不适合新手,设计模式也不适合新手,这是我最常听见的却坚决不认同的言论。网络上有个帖子《图灵奖得主Alan Kay告诉你计算机业可怕的真相》,其中有句话“你的计算机知识是由错误的人使用错误的资料教给你错误的知识。” DDD和设计模式承载的思想,就是一种认知世界的方法,新手越早学习,以后的路就会越顺。唯一的问题就是如何把这些浅显而深刻的思想传授给新手,而不是用类似的口气:“你还早呢,你先把牛津字典背完(各种语言细节),到时候再看莎士比亚的著作(语言如何描述思想)”。更可怕的是,看惯了八卦新闻、口水文章(各种糟糕的代码、项目),再也无力欣赏大师的作品了,更无从谈起追随大师,学习大师的思想了。

5)sun对模型的解释:Model - The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model.

6)"D. Hilbert曾经说过:如果随便在大街上找一个人,你能对他说明白你现在正在做的数学,那么你做的数学才是好的数学。H. Wyle曾经回忆说:在哥廷根,Hilbert就像一个吹笛人,他优美的笛声使得我们这些老鼠都跳到了数学的大河里。"Hibert是谁?20世界最伟大的数学家之一!再深奥的数学都可以跟对数学一窍不通的人谈,这才是好的数学,就像苏格拉底在大街上可以随便找一个人讨论哲学,不管这个人是老人、小孩还是女人。

7)领域建模与设计模式的思想不是只有高手才能领悟,就像数学与哲学思想不是只由数学家和哲学家才能领悟。思想与知识是两个相关又不同的范畴,建模思想与技术知识/经验同样如此。不要因为新手知识的不足,而认为新手就不能领悟思想。如果出现这种情况,我只有两种理解:a)这个老手不懂;b)这个老手懂,但不想告诉你,可能出于自私,也可能觉得你还不适合。

8)我的言论,作为老手或高手的你可以看不起或不同意。但我心中的真正高手、大师并不多,我自己会努力找到他们,并从他们那里聆听他们真正的智慧。