领域建模过程的产出——容易被忽略的核心环节

早期学习笔记，按照现在的观念已不再推荐复杂建模设计，仅供参考。

这段时间看了不少有关DDD领域驱动设计的文章和园子，基本将思路一缕一缕的缕顺，实在非常感谢他们的经验分享和交流，但是自己也绕了一大圈弯路，总的感想就是：累晕醉。

领域驱动设计的广泛评价是个好东西，也有评价把问题搞复杂了的，大家有目共睹，我就不发表看法了，我只针对其中值得学习的方面进行研究，结合自己的实践来得出总结。在我绕了一大圈之后回来发现，其实领域驱动设计真正有价值的东西，就是这个领域建模。然而网上基本是架构实践的东西，却很少有建模肝物，这就导致除此接触DDD的人很难看全一个整体，见尾不见首。我等有时间再整理有关建模的内容。

如果开发过三层架构，对于DDD的经典4层一般人都很容易理解，关键难点在于把握其目的性，4层因何而来，聚合、实体、值对象因何而来，始终没有一个贯穿前后的说法，甚至被认为用了DDD就应该这么分这么干。

当我看了一些例子，我开始懵逼，开始不理解，我就会想到以下问题：

底要解决什么问题？

问题有没有得到解决，效果是否让人满意？

为什么要这么干？

这种做法来自于哪里，由什么来指导？

这种做法能形成统一观点吗？

那有什么依据要这么做？

你能接收这种做法吗？

经过这一系列的反思，在那些看似合情合理却又无从理解如何下手的例子中，我找到了弊端，都是惯性思维在作怪，在这些所谓的实践例子中，严谨程度并不高，当中缺失了很多定位和过程内容，根据作者的思路跳跃性的开展，篇幅很大，坑却很多，让大多数人觉得（也包括本人）认为，一个完整的套路就是如此，殊不知建模这个步骤并不是一脑袋一拍一步到位的。

例如软件的开发模型——瀑布模型，或者V型，都明确指明了每一个阶段所创造的内容以提供给下一阶段，用户需求-->需求分析-->系统设计-->其他各种文档。领域建模是有多个环节组成，每个环节都能够为下一个环节提供必需的清单。根据我的整理，通常的流程如下：

1、主要业务流程图

2、角色划分图及其说明（根据1列出所有角色及其关系结构）

3、用例图（根据2得到每个角色的用例）

4、领域个体图（根据1、3得到一个个单个的领域对象，同时产出领域边界描述，但是此时的边界描述可能还是模糊的，在后续每个步骤都会得到细化）

5、领域关系图（根据2、4得到领域之间的相互依赖，划分出核心领域）

6、角色-通用领域图（根据2、5将角色加进来，划分出通用领域）

7、四色原型①（只需要role-MI属性关系图，将6中的角色和领域逐个对应，产出服务、角色属性）

8、四色原型②（根据7加入ppt，将6中的角色归类合并，对应得到ppt对应的实体、属性、值对象）

9、针对7、8一致性、并发性、事件要求等说明

10、仓储、应用、服务、模式

11、其他落地过程（数据库设计、并发、消息、接口、适配、架构等等......）

任何一个不规定每一个环节的必需品和产出物的开发过程，都是耍流氓。

有的给出聚合模型，但是流程图、用例图，产出物和必需品只字不提。

有的将领域图直接当做流程图使用，或者反过来。

有的给出的领域图都是草图，非常不严谨。

有的从流程图直接跳到类图聚合，虽然提到领域，但是没看到任何转化过程。

有的具备了详细的领域图解，讲了一大堆概念，但是接下来何去何从、如何接应，没有然后。

人就是这样，总是质疑商店卖假酒，却从不想酒为什么是假的。如果你还不能脱离那种动不动就来句show me the code，那么你的思维还是停留在程序员阶段，而不能算开发人员。路是走出来的，模式是总结出来的，思想是靠变通出来的。数一数拌过的坎，爬过的坑，幸甚至哉。

《领域驱动设计 软件复杂核心应对之道》这书中，大量的篇幅都用来阐述模型，并围绕着建模、分离、重构展开。我认为，领域驱动设计就是一种建模学说，它所主导的方式就是从面向业务领域的层面开始思考、分析、建模，它的范围是一种思想、一套概念，因此没有提供任何实现方式。换而言之，就是将以往直接从业务用例中提炼对象的方式，上升到将业务作为对象的层面，其本质还是基于面向对象的，区别在于面向的粒度和高度都更广更高。

领域驱动设计的核心就是建模，例如根据领域驱动所得的产出物（聚合、实体、值对象、仓储、服务等）都根据四色原型分解提炼，因此建模是一切产出物的开端，如果这个开端都没有做好，何来后面的正确的架构设计和编码？而我发现很多相关文章，从实践到讨论最后都演变为就一个组件如何跟领域驱动设计的定义对号入座而争论，领域驱动设计被超出其本职地当做设计模式来看待，而建模总是被忽略，让不少新手一脸懵逼的进来，一脸沮丧的离开。

不要为了模式而模式，四人帮《设计模式》曾告诉过我们，当你为了解决某个问题而想到了一个套路，产生一种模式那是再自然不过的事情了，当遇到类似的问题或场景，不应该想“怎么用”，而是应该想“考虑用”来用应对之。否则就是生搬硬套，何来快感？解决问题能力很强的人不在少数，但是思维变通能力很好的人却不多。解析和讨论，有时候需要保证思路不越界，有时候也需要适当的跃迁，我们的讨论或文章，大多都没能维持这一点，总有一种习惯：能用的都要用上，能扯上关系都要谈及，唯恐显得知识面不够宽广，唯恐显得肉馅还不够多。《设计模式解析》，他们能在一个问题范围内紧咬着思路，做出质量很高的解析，领域驱动设计虽然不是上古时期的产物，但是在九十年代能够给出一个当时没法落地的颠覆性的设计理论，也是前无古人了。