领域和场景到底有多少不同，可以这样想：当领域一个角色，一个交互的时候，他到底与场景有什么不同呢？

对于DDD中的面向领域中的“领域”，我们要看看实际情况中，我们得到的领域，到底是不是客观的。

客观领域——（领域专业人员）——》？——（建模设计人员）——》模型

从实际中，建模设计人员看到的是什么？是领域的一个描述，一个解析，这个领域是从领域专业人员中得出的。正如banq之前所说，我们建模设计人员不可能精通每个领域，所以我们需要需求分析，客户资讯，而领域专业人员可以是软件公司的，可以是用户公司的，可以是建模人员自己。

从上图我们可以看出建模设计人员，很少直接接触客观领域（当然，把领域专业人员与建模设计人员合并也是有的），他们得到的永远是一个主观概念，而正因为如此，这个概念是变化无常的，无论在开发过程中，还是在开发完成后。所以对于建模设计人员来说，他们所面对的领域是别人所给出的，是一个不稳定的领域（即？=主观的领域）。而敏捷开发是把领域专业人员与建模设计人员之间的传递缺失减到最少，而且响应快，但变化依然存在。

那么回过头来，建模设计人员+领域专业人员=？我觉得是某些领域的建模专家。如，银行借贷存取领域的，批发零售的，论坛领域的，医疗领域。这种人员适合，成本大批发型软件，如金蝶财务一类。而前面的适合多种不太大领域的。

在以上的论述下，DDD中domain就是？了。为什么jivejdon领域中只含有基本的论坛基本的东西呢？因为banq从客观中获得的论坛就是这样，另外一个侧面说，banq获得自己的需求就是这个。
[该贴被SpeedVan于2010-12-16 10:01修改过]

这个很有意义，也能回答DDD和传统需求分析设计的关系。鉴于我上个贴提出“需求”这个词语比较有人的主观成分，所以，需求应该是和目标类似的，说白了，就是最后软件系统的测试员，是软件功能质量检验目标。

最初的需求就是应该含糊的，是总体的，这时领域专家介入，开始领域建模，包括边界划分，纲举目张，然后通过MDD或MDA迅速生成代码，由需求人员检验，他们如果肯定基本方向，就是肯定了你的领域模型，那么就会在此上面继续提出需求的细化目标。这实际是一个敏捷过程。

希望需求人员一开始就提出很细致的目标，实际就是强迫需求人员做领域建模的事情，让他们在自己要求的目标和在客观世界中发现领域，提炼模型两件事情一起做了，这个素质要多高，在他们UML都不会画，都没有合适表达他们的需求，只有靠文字表达需求的阶段，这很显然是有问题的。

软件开发就是一个创造性活动，这个创造性活动是需要多个领域人员参与，不可能靠一方人员单挑，创造性活动的本质就是在过程中创造，如果过程还没有，一切都是纸上谈兵，根本就不是创造性活动，而是设计好的执行落实。

总结一下：需求大目标 -->领域建模 --->软件运行演示 --->需求小目标 --->模型精化重构 --->运行演示。

上面谈了需求和领域建模的关系，就像一个人打110求救，求救是需求，警察到现场，就要开始分析，就是领域建模。

关于业务集成，其实在DDD一书的维护模型完整性以及限定上下文说了，总体精神就是：不要一开始就去抽象合并，而是尽可能的细化，对于每个模型都要套上场景(也就是限定上下文)，两个模型能统一成一起，那是难得碰到的事情，是天上掉的馅饼，这个工作也只有等复杂系统全部集成完成以后，重构时进行。

那么两个模型相似，又不能合并，不是很麻烦吗？那么通过数据转换，DDD书中作者以routingService和NetworkTraversalService数据转换为例子，说明每个模型都要带个场景帽子的重要性。

其实如果想抽象共性，目前只有静止的数据大概才可以，所以有DCI，DCI中Data是数据静止，也就是特征，区别于其他事物的特征才是唯一共性，一旦和行为有关，就涉及场景上下文，就有角色，就已经很具化了。

[该贴被banq于2010-12-16 11:39修改过]

我在和别人沟通时也说需求是目标，是范围。但别人会反驳我，说我说错了，呵呵。对于场景和领域我还没有思考过
[该贴被xuzhh于2010-12-16 12:35修改过]

呵呵，banq见多识广，我不知道传统需求分析设计和敏捷开发，也没看过DDD这本书（是个软件开发的新手）。DDD给我的启示只有一点，就是提醒我“用领域语言思考领域问题”，剩下的就根据自己的常识和对技术的认识进一步思考了。

banq的总结的开发过程是实战经验出来的，肯定是有道理的。我这里从另一个角度，语言的转换角度来总结开发流程，希望是一种补充：

用户需求 =〉提炼领域语言 =〉使用领域语言描述领域的模型与活动 =〉将领域语言转换为OO语言（可以是别的语言） =〉 使用Web与DB语言支援OO语言的描述 =〉将OO、Web、DB这些技术语言转换为机器语言

每个转换翻译过程，可能需要分工，比如我们已经习惯了将OO、Web、DB这些技术语言转换为机器语言的工作交给编译器或解释器来做。而前面语言转换的若干过程，如果是有明确的分工也不会有什么问题。

可是，学习初期，我们面对的用户需求往往比较简单，可能形成了“将前面这些语言转换过程可能同时进行”的习惯，而后又将这种习惯沿用到解决复杂的用户需求了，这将出现许多意想不到的疏忽和混乱。

当然这一整个“语言转换链”需要走多次，往往不能一步到位，这是符合常识的。先将核心需求的原型构造或表述出来，检验这个原型，再在核心原型上打磨，添砖加瓦都是有可能的。

葛优这个“演员”（模型），也可以在心中多部“戏”（场景）中演多种角色，葛优的演戏功力，就是这些角色的潜在共性，而葛优身上的演戏功力就是“模型”的一种“行为”，数据可以抽象，行为也可以。（这好像不是抽象，就是显而易见的事实而已。呵呵）

DCI是把“交互行为”(interaction) 从“数据模型”(data model)中抽离出来，分布在各个“场景”(context)中，但不是把所有行为抽取出来，非交互行为（比如葛优自身的演戏功力）还是留在“模型”中。

对banq的回复，有那么一点理解：

是否可以如下设想

客观领域——（用户思考提出）——》业务需求——（领域专家从业务中，反过来获取原来的领域）——》领域（注：这个领域是客观领域的次品）

也就是说业务需求是领域的正转化的话，那么从需求中得到领域就是一种逆转化。

那么需求就如同DDD中的应用层，是领域的组织。

其实我们所说的领域是业务需求还原客观领域的结果。

有种现象是，即使是业务改变了，之前得到的领域根本不需要改变。

这个赞同，jdon007不愧是007，洞察力很强。
关于哪些行为和场景相关，哪些行为应该留在模型中，这就要对行为再做一个仔细演技，"职责驱动设计"一说对这个写的很系统。

职责驱动设计和领域驱动设计看名称好像矛盾，其实应该是推进。领域比职责的边界范围要广。

职责驱动设计要领：

roles-and-responsibilities模型：对象扮演不同角色，实现不同职责。

把应用的职责切分到接口中成为其方法。然后实现职责行为之间的交互。用接口实现职责，一个实体实现不同职责的接口，或者通过Domain Events驱动不同的接口。

如何从职责和协作中发现丰富对象？