最近在一个网站上学习DDD，整理一些别人的讨论，个人觉得非常重要，分享给大家。

Question

下载地址：
http://files.cnblogs.com/netfocus/DDD_Notes.rar网站地址：http://www.jdon.com
首先声明，我并不是在为了自己好而宣传那个网站，那个网站也和我没有关系。我只是觉得那个网站中的内容不错，所以想推荐给大家，仅此而已。
如果觉得好，就顶一下吧。下面截取几个他们讨论的片段：
什么是领域？对某一科目分类划分后，对应的各部分就叫做某某领域。业务领域就是边界，为什么业务领域会有边界呢？如何确定边界的大小呢？那就是领域模型，那我们再看看领域模型的定义：领域模型是领域专家和分析人员互相沉淀知识的一个工具，它帮助分析人员理解领域知识，也为领域专家提供一个规范的表达形式，有条有理的描绘领域知识，分析、解决领域问题。另外，领域模型也是开发团队知识沉淀的一种方式，帮助开发人员了解他所从事的特定领域，提高建模技能。领域模型其实是一种语言，领域专家与分析人员、开发人员之间交流的通用语言。
1. 领域模型不是图，图只是让核心、关键的概念清晰的呈现出来。图的表达能力有限，模型必须配备描述（需求采集会议中的口头描述，或文档中的文字描述），将图形所代表的意义，以及图形中没有呈现出来的规则、断言、细节进行补充，才能完整地表述需求。
2. 领域模型的UML或者类UML图不能太细太完整，否则过于庞大的模型会干扰人的思维，阻碍对主要部分，或者复杂逻辑的梳理。业务总是被切分成一个个片断进行分析，在每一个片断里，画出几个主要的对象和交互逻辑，细节的部分用文字记录、描述。
3. 领域模型中不应当出现设计、技术方面的术语，也不应当出现开发人员不理解的业务术语。
领域模型是领域核心，是决定领域边界的关键。不过我感觉领域模型有内涵和外延之分。上面关于领域模型的定义，我感觉更多说的属于外延部分。因为业务是变化的，那么领域模型也会发生变化，关键是我们要掌握驱动业务变化的核心，即驱动领域模型变化的核心。先谈谈现实业务中的问题域模型，这个模型不是“领域驱动设计”一书中的“领域”，那个“领域”更侧重强调是“领域模型”。可惜目前似乎还没有一种办法能够去立体化并动态地完整描述这个“问题域模型”。为什么我要强调这个东西，就是让大家想一想我们为什么要需要“领域驱动设计”。其实我们有一个永恒的技术使命，就是要解决“问题域模型”的变化问题，因为“领域模型”会存在与”问题域模型“不匹配的问题，这个可能是时间变化或者用户场景变化的原因造成的。对”领域模型“的检验标准就是看是否能适应”问题域模型“的变化，其中”开闭原则“是在这里适用的。
    所以对"领域驱动设计"的第一层”驱动“的含义，我觉得是"问题域模型"驱动"领域建模"以及"测试建模"。从这一点来说，"领域驱动设计"是适合一切场景的，而有人说”领域驱动设计“有问题，准确地来讲是目前的"领域建模技术"还不完善，当然也可以说是"领域建模技术"的运用有问题。这就像最近有人说"面向对象编程走错了路"，其实并不是真的说OO错了，而是说"传统OO"有很大的缺陷，首先第一条就是"没有面向消息的传递机制"。对于有人说“领域建模”只适应“稳定领域”，我并不赞同。我认为领域建模的真谛是认清业务发展变化的脉络，其最高境界就是“庖丁解牛”。因为真实世界中并不存在“稳定领域”，业务的变化是一种永恒。如果业务永远不变，那就我们就真的幸福了，只要满足用户需求，怎么设计都可以了。关于"领域驱动设计"的第二层含义在上一个帖子里已经分析过了。
总结一下，"领域驱动设计" = “问题域模型驱动领域建模” + “领域建模驱动软件实现”。

Answer 1

我觉得重要是因为我觉得他们讨论DDD，也就是领域驱动设计的时候非常深入。并不是仅仅从纯技术的角度来思考问题，而更像是从一种哲学，认知学的角度去思考问题。我希望这里的人也能在看了后能引发一些思考。相信我的眼光把。

Answer 2

关于领域驱动设计（Domain Driven Design），简称DDD，我从网上搜集资料，整理了以下几点个人感觉比较重要，应该引起我们不断思考其中的精髓。喜欢学习领域建模思想或理论的朋友可以参考一下，而只注重实践的朋友可能不需要太关心了。
1) "领域驱动设计" = “问题域模型驱动领域建模” + “领域建模驱动软件实现”
2)  问题域建模的过程就是业务领域分析的过程，对于企业而言就是业务架构的分析和建立过程，这里不包含任何OO的设计成分，主要从组织、流程和业务能力三个维度来分析业务。
3) 记住很多模式没有什么用处，带着问题在模式中寻找答案才是正确的使用方式，让那种解决方案的思想融入到你的模型当中，然后彻底地忘掉那些所谓的模式名词。
4) 好的领域建模应该具有柔性，能够伴随着用户一起成长。
5) 《领域驱动设计》一书中只是强调了业务的水平分割，然而在大项目里还有垂直分割，注意垂直分割不完全等同于包的划分。目前有一种非常错误的做法，就是一上来就开始对象建模，然后再进行归类划分模块；正确的做法应该是前期以确认领域边界功能为主，后期以确认领域内的对象模型为主。关于领域的切分，《领域驱动设计》没有过多谈及，其实方法就是不断对企业业务知识的学习和分析。当你对一个业务认识不清的时候，最好的办法就是不同企业环境下去分析这个业务，那这个业务的所有发展变化就清楚了，这就像那些生物学家总是喜欢通过长期的野外考查来学习知识。这个工作做好了，项目就成功了50%。
6) 领域的边界就是服务，也是对外提供服务的唯一入口。领域服务和领域对象模型是一个业务领域的2个不同侧面。领域服务强调是从外向内看，反映了“外部对业务领域的使用功能”；领域对象模型强调业务领域就像一个独立的具有一定自主能力的生命体，反映了“业务领域的内部运行机制”。领域对象模型的功能是不能对外暴露的，不然会造成外部对领域对象的耦合。
7) 不要一说“面向关系设计”就是错的。因为用户的角度看，业务本来就是面向关系和过程的，这非常自然；而从设计看，业务是不同主体在相互作用。这就是为什么越靠近用户的地方面向关系和过程的设计味道越浓的原因了。
8) “类和职责”的叫法让我总感觉比较僵化，像是没有生命的死细胞一样，觉得这是一种西医模式。我更崇尚一种中医模式，强调建模是动态的、基于场景交互的，应该用更自然的还原业务本来面目的眼光去审视建模过程，也就是说“有机的业务建模”实际上就是“技术建模”的问题域建模，而“技术建模”只是“业务建模”的技术落地而已。
9) 关于建模工具，像“用例图，流程图，状态图之类”的并不是我理想的建模工具，虽然他们确实能表达一些东西。我理想的业务建模工具应该是能从角色（组织或者人）、流程、业务能力三个维度立体地、动态地分析描述业务模型，希望可以是一个动态的3D视图和流图，并可以按不同的维度分析展开。
10) 那对于我们做企业业务建模，终极目标应该是个什么样子呢？我认为这个终极目标一定是非常复杂的（也就是我原来常说的大项目场景），因为只有在复杂的场景下才能真正检验各种建模技术的偏颇。想想看，我们的建模目标应该向谁学习。论坛也有人说过，“自然的就是最好的”。是啊，经历过亿万年才进化出来的模型难道不值得我们学习吗，难道不是我们的目标模型吗！呵呵，答案已经呼之欲出了，就是“仿生物建模”。是的，没错，如果说利用我们的建模技术能够去构建出一个复杂的仿真人，具备人的一些特征和功能的话，那这种建模技术就是完美的。
11) 企业的业务建模可以分为两个层面，”宏观建模”和“微观建模”。“宏观建模”是指首先要对企业做一个整体的信息化规划，对企业进行整体的的业务架构建模，其成果就是业务组件。其中的方法论可以参照IBM的CBM，不过IBM好像也只是咨询，真正的落地还要靠自己对CBM的领悟。
    Evans的DDD主要属于“微观建模”部分。对于“微观建模”，我认为分为2个方面：“结构化建模”和“行为建模”，这是一体两面。我觉得Evans对DDD总结了几个关键的要素：实体、值对象、聚合、工厂和存储，但其中还少了一个非常重要和关键的要素：“事件”。
12) 众所周知，人体是由很多细胞构成的，那细胞之间是如何作用的呢，其实就是“刺激”和“响应”。其中“刺激”就是“事件”，所以“事件”是业务模型本来就应该具备的要素，而不是什么技术层面的东西。从“事件”角度看，“职责的本质就是事件的响应”。
13) “结构化建模”是指建模中除了静态的实体和值对象的结构关系外，从“事件”角度看，实体或者值对象还具备一些“本能的反应”，比如"手指会弯曲"。而“行为建模”是指通过神经中枢（消息总线）来控制不同对象的本能反应来完成一个复杂的组合，比如"用手弹钢琴"。