重温了一下DDD，感觉很多都清晰很多了。

我发现自己是弄绕了领域，业务描述，需求。

若果客观是一个世界的话，那么在世界画一个闭区间，这个区间就是领域——内容是客观的，但是是主观地加上了边界。

需求，是用户描述这个闭区间的意图。

业务描述，是用户对这个闭区间的一种不一定全面的描述。

客观主体与领域的关系，这里的客观主体若果是闭区间的内容的话，那么可以说客观主体==领域。这里可能有点不同于jdon007的理解，我并不理解为共性的，我理解为“the”，即特别的。若果也以电影为例的话，那么“这部电影”才是领域，“其他电影”就等同于其他领域，即使他们有相同的地方，或者完全相同，也只是“领域模型”可以复用而已，而不是领域相同。也就是jdon007的例子中全部加上“the”，就是我的理解了。

那么“领域模型”到底和“领域”是什么关系呢？
[img index=1]
我个人是把“领域模型”作为“领域”的一种描述，其地位与用户解析业务一样。相当于，用户用中文告诉我们，我们再用英文翻译而已。

[img index=2]
用户发现自己之前的描述出现纰漏，那么也就是用户自己的描述改变而已，领域并没有改变，但是注意这种业务增加是不改变原领域的。若果是增加业务，那么是属于领域边界扩张。若果当领域改变的时候，也就是不再是这些演员导演等人了，或者不是拍这步戏了，当然了，是否改变是需要分析的。

业务变更了，领域是否会发生变化？这不能确定，这要看这个业务变更是因为什么，若果因为用户描述纰漏而造成的，则领域没有改变，若果是用户所在的公司，业务扩展，则是一种领域改变。

领域的圈子是用户自己给的，他根据自己的圈子作出描述，领域建模人员则是根据对方的描述，自己的知识和实地考察，尽量获取出用户自己本来想要表达的圈子和圈子中的内容。若果用户本身的想要表达的圈子变了，那么领域就变了，（论坛变大型SNS，明显是圈子上的变化），至于到底是扩展，还是完全不同，就另外再说吧（其实扩展就是与原来不同嘛，AB->ABC，AB!=ABC）。

我们领域建模人员不但要找出用户所要表达的圈子，还需要了解圈子内的内容。说到底，其实是领域当中既含有主观的东西，也含有客观的东西。

[该贴被SpeedVan于2010-12-17 13:37修改过]

To jdon007
  这里没有谁看不起谁的问题，也没有什么老手看不起新手的问题。我希望这里是一个用自己的实践来“印证”DDD的园地。对于用自己只是听说的东西来说事，在我看来是一种不尊重，也会误导大家。为什么这么说，从你言谈看不出来你是电影专业人士或者做过电影相关业务的人，让我感觉对大家不尊重。你可以看看SpeedVan的回复，先不说其观点的对错，但一看就是自己实践中来的感悟。希望大家都能遵守这一点，这也对jivejdon的爱护。

DDD这本书开篇第一章第一节就是一个中国18世纪的地图，什么意思？地图就是模型。

模型是主观色彩的，领域模型就是领域中的模型，领域是一个中性词，只有业务领域和软件领域等概念，必须前面有定语，领域本质是指定一个界限。如果说"领域是有一定主观色彩的客观存在"，这个结论没有意义，任何语言的词语都是有一定主观色彩的客观存在。

"既然领域有边界，那么一个客观主体自然会有多个业务领域"
注意："领域有边界"也是无意义的，领域就是边界，你相当于在说“边界有边界”，这个太绕了，别忘记我们讨论核心是领域中的模型，而不是领域本身，领域分业务领域和软件领域，要讨论领域，也就只能讨论业务的领域和软件的领域。

好了，我们来统一的单词，我们只能有三个：业务领域 软件领域，和领域中的模型。如果你想引入”客观主体“等单词，这个我个人很难以理解，语言词语很多，大道至简，不要引入太多词语，因为我们重点是模型。正如DDD书籍开篇第一章就是谈模型。

"常用知识来描述领域，这种知识分析抽象的结果就是模型。领域和模型可能是一对多的，但应该尽量地少。"
你总算谈到模型了，领域和模型关系没有必要讨论，因为领域是一个范围，里面有多少模型没有规律，如果你想从这个角度得到什么规律，我个人认为会落空。

"按理说领域应该是相互独立，其对应的模型也相互对立，这是理想情况。可现实却不是这样，因为我们在做业务分析时往往由于自身对领域知识认识不够而根本就没有划分清楚"

按理说领域应该是相互独立，其对应的模型也相互对立，这不是理想情况，而是我们的目标，需要通过重构来达到，Account那个案例不恰切，主要原因还是我们对实体参与不同角色做不同交互有分歧，你没有真正理解jdon007的角色扮演的意思，不要把场景和领域混淆在一起，领域只有业务领域和软件领域，场景有很多，场景也有边界，分界限上下文和邻居上下文。

"其实业务或者领域是否稳定不是关键，对我们最有意义的是如何保持模型的相对稳定...我尤其感觉DDD的聚合在形式上比较僵化"

"业务或者领域"就是业务领域，我们有时简称领域(如果上下文正在谈软件概念，突然提到领域，就是指业务领域)，业务领域是否稳定不能左右，重要的不是保持模型稳定，而是让模型能够真正反映业务领域的本质，合着业务领域中本质旋律。所以，维稳与跟随是两个不同境界，维稳带有强制性，跟随是顺势而为，耐心静观其变，知微见著，采取灵活的变化措施，唯一不变的是变化本身，灵活敏捷跟随变化才是唯一之道，不要幻想稳定，稳定就代表不运动，就代表死亡。

为什么你觉得DDD聚合形式上僵化，我前面已经从冰块到量子力学以及数学公式，说明一个规律：任何物体都是因为聚合成为事物；如果学习过UML，都知道类四大关系中最重要关系是关联，聚合是一种高关联，是组成的关系，万事万物都是组成的，轿车是由车身 马达 车轮组成，物体是由分子原子组成。所以，组成也就是聚合是自然界最普遍的关系，这是面向对象OO最重要的观点，

两个重要基本概念：边界和组和(聚合)，任何事物有边有界，任何事物是大由小以组合这种强烈聚合在一起。其实事物内部的组合也是一种边界划分延伸，这就更深奥，不是所有人都能明白，然后才能明白，我的屁股决定脑袋，身在庐山不识庐山真面貌的意思。

"然而由于我们往往对业务领域边界认识不清楚，所以“不是边界不稳定而是我们根本就没有分清楚边界”"
这个赞同，狗和动物狮子老虎除了吃喝撒拉这些基本需求外，一个重要本能就是标记领界，如果有能力搞定小领域，就能搞定大领域，你的地图领地就可以不断外扩，原来的领域就变成了子领域。
所以，不是我们对领域边界不清楚，而是你是否能搞定领域内的模型(模型其实是大边界内的小边界)，一屋不扫何以扫天下。领域专家就很重要。对领域专家的尊重就是对自然规律的敬重。

[该贴被banq于2010-12-17 15:56修改过]

“领域就是边界”，那么边界是一个壳的话，那么领域是否也是壳呢（不包含其内在）？那么我们建模到底是建内在模型还是壳呢？我认为边界是主观添加的抽象，他是区分“是X”和“非X”的一条界限，但他不是“是X”或者“非X”。这个可能就是出入的地方了，弄清楚就开朗了，望反对意见。

我觉得你把领域代表的边界和模型中的边界可能搞在一起了。上面帖子本来觉得复杂，没有写下去，谈到这里，就写下去，不知我能否说明白，大家能否看明白，权当胡言乱语吧。

谈到边界还有些具化，再抽象拔高点：空间上是由大空间里套小空间组成的(同样，时间是由长周期套小周期组成，这个规律适合炒股，呵呵，题外话)，何为大小空间，首先你要区分边界，把大和小划分出来；

下面是关键的：大和小划出来以后，要考察大小之间关系的紧密程度，比如我们先约定在A空间开始分析划分，A里面有B，B里面有C，C里面有D，不仅仅如此，我们发现，B和C的关系非常紧密，有一种内聚机制，也就是原子或分子吸引力强，那么，B实际是由C组成的，他们是一种组成聚合关系，当然，作为C的组成部分D也是B的最底层组成部分。这样，我们就有了A空间为领域(或子领域或场景上下文)，B为模型的划分。

有可能我这些解释不是你问的意思，最后我再重复一下，我们建模当然是建领域中内在的模型，这是终极目标，我们是通过不断缩小包围圈(壳)来接近那种边界之间聚合很紧的模型。模型是目标，领域边界是前提(场景也是前提)。

[该贴被banq于2010-12-17 16:40修改过]
[该贴被banq于2010-12-17 16:41修改过]

我承认自己的项目实践经验“远远不如你”，可是这不表示我“不写代码（实践）、不阅读、不思考”。我只是尊重常识，按常识思考。因为缺乏足够的经验，就变成乱说话了？对大家不尊重了？误导大家了？人云亦云了？你很擅长帽子变戏法，一下子给我带了这么帽子，好运气从天而降，看来我要谢天谢地！呵呵。

我的言论的大部分也是从原创者那里学习，经过自己不断思考，并尝试编写一些代码例子而得来的。还有，比如四色原型，为什么我曾说一见如故? 那是因为我在非软件领域对与其相似之物有过一段长期的思考。

我把一个少女比喻一朵鲜花，你却说“从你的言谈之中，我看不出你是植物学专家”。用花作比喻就是对植物学家的不尊重，对听者的不尊重。好，那就这样吧。我服了。真的服了。不说了。

这是什么意思“接近那种边界之间聚合很紧的模型”

banq,虽然很费劲，但是讨论清楚了一些，下面继续。

再一次精读DDD的第一章开头，感觉已经明确了。

“18世纪的中国的世界地图”是适用于那个社会的世界模型。从这句我们可以看出领域是世界，而模型是适用于当时中国社会的（世界）地图。领域，是存在无限多的元素{ABCDE...}，而这些元素的非空有限集合(如[ABCD][AB][ACD]）就是领域模型。所以，领域存在无数个领域模型。而我们则选取或者发现对我们有用的模型。如一个银行，它含有柜员机，柜台，椅子，保安，各种业务，又有投资的，各种人员，各种职能···总之在一个银行领域里面存在无限多的元素，现在这银行需要一套软件，这套软件肯定有目的性，如只是协助投资业务办理的，那么在这个银行领域里面，与投资业务相关的东西所组成的有限组合，就是我们想要的模型。（注：“非空有限集合”是我自己理解出来的，至于是否准确还需实践验证）

在DDD一书中有这样一句话“每个模型都代表了我们所感兴趣的现实或观点的某些方面”，银行是我们感兴趣的领域，而投资业务是我们所需要的模型。所以可以说模型是领域的简化版（把无关的东西忽略掉）。注意，这句中“现实或者观点”说明了，领域不一定是现实客观，也可以是主观的知识领域。例子，之前banq说到的算法领域，当中排序算法（有限集合）就是一个模型。

领域的选取也很有讲究，如银行中需要这个投资业务软件的只是当中的XX部门，那么这时我们就应该选取XX银行XX部分作为领域，也就是说，尽可能把定语提取出来，缩小领域范围，更早得到所需要的模型。

“用户在其中使用程序的主要环境称为软件的领域(domain)”，这句更能比较准确的找出领域，同时也是找出领域的依据，句子中一词“环境”很有意思，它与“领域”都是一个抽象的词，指的都是包含一个范围内的所有东西，这个“所有东西”不是我们所能全部列举出来的。若果“领域”太过专业术语的话，初学者更能接受“主要环境”（“环境”相当于“域”，“主要环境”则是“领域”，而“主要环境”中想要的东西就是所需要的“模型”）。

至于我之前所弄绕了的，正如banq所说是边界弄在一起了。“{}”这个是领域的边界的话，则“[]”这个就是模型的边界，而因为领域中的元素是无限个，所以领域边界和模型边界不可能重合。

而对于修改与扩展，是针对模型而言的，用户的需求就是所需要的模型，模型会根据需求而变化。而扩展能力则根据一开始所选取的领域有关，领域越大扩展力越强，但相对地前期工作量也会大幅度提升。例如，我一开始就定为部门内，那么相关东西则是以“部门”为定语了，如“部员”，以“部门”为定语的扩展基本是很轻松的，当想突破原来领域的界限的话（“部员”变成“员工”），则是一种领域改变（{ABCDE...}->{aBCDE123...}），这样的代价是很高的（某些模型的改变，一些原来忽略了的关系和交互需要增加），至于想重构或者是重新开发，则是另外一个话题了。

还需注意DDD和MDD其实不是同一样东西，即使想领域最终会回归到模型，但是DDD当中更多的是领域的思考，如何去获取准确的模型，而MDD是模型驱动，也就是已经获取了模型之后了，也就是基本不考虑领域的问题（如究竟定义为“部员”还是“员工”并没有考虑）。可以说DDD考虑得更全面些，若果一个软件属于一次性定型的，那么MDD也是可行的。什么叫“XX驱动”，就是“以XX作为基础，围绕其进行活动”。

是的，DDD是领域驱动设计，而MDD是模型驱动开发，最后一个D的含义不一样，DDD是前面，侧重获得领域中的模型；MDD是后面，侧重于将这些获得的模型转换为可运行代码；MDA是和MDD并行的，也是将模型变为可执行代码。

DSL属于MDD一种，UML和MDA捆绑在一起，前者是字符式；后者是图形式，字符式和图形式的各有优缺点，中国人喜欢图，觉得画画图就能开发出一套软件，很方便，这其实和国人象形思维有关，汉字都是象形，所以，国人骨子里好这口；

而字符式的属于纯逻辑型，就像英文字母一样，本身无任何意义，逻辑藏在无意义后面，迫使使用这些无意义符合的人需要有逻辑思维。所以，MDD或DSL不太合国人胃口。

这也是为什么国人软件落后的原因所在了，文化促使其有天生偏向，而这个偏向又不是站在现代科学的核心“逻辑”这块，天生短处，无法短时间弥补。

我比较罗嗦，谈谈就谈开去，主要能碰到能谈开去的人和话题，哈哈。