在软件领域，说到“建模”，就会蹦出各种各样的名词：面向对象建模、业务建模、领域建模、UML建模、ER实体建模、4色建模法、DCI。。
这些方法之间有区别，又互相有交叉；有的比较新，有的是以前的老方法。混在一起，很容易让人”云山雾罩“，讲来讲去，不知所云。
然后学的人，很容易照葫芦画瓢，画各种看上去高大上的图：业务流程图、类图、交互图。。但仔细一深究，又是到处漏洞，图不能完全表达义务语义，“华而不实”。
本文希望跳出这些方法论的框框，去思考一个根本性的问题：建模的本质到底是什么？
有兴趣朋友可以关注公众号“架构之道与术”， 获取最新文章。
或扫描如下二维码：
建模的本质 – 重要东西“显性化”
很多时候你会遇到这样的情况：一个函数写了几百行，里面的if-else写了一大堆，计算各种业务规则。另一个人接手之后，分析了好几天，才把业务逻辑彻底理清楚。
这个问题从表面来看，是代码写的不规范，要重构，把一个几百行的函数拆成一个个小的函数。从根本上来讲，就是“重要逻辑”隐藏在代码里面，没有“显性”的表达出来。
这只是一个函数，推而广之，到类、到模块、到系统，是同样的道理，比如：
业务流程隐藏在多个对象的复杂调用关系里面；
某个业务核心概念没有提取出来，其职责分摊到了其他几个实体里面；
系统耦合，职责边界不清。。。
所以，个人观点：建模的本质就是把“重要的东西进行显性化，并进而把这些显性化的构造块，互相串联起来，组成一个体系“。
重要的东西 – 构造块
那么哪些东西是”重要“的呢？ 比如领域实体，比如某个业务流程（对应到DDD里面就是”领域服务“），比如某条重要的业务规则（对应到DDD里面就是Specification模式），比如复杂对象的创建过程（对应到DDD里面，就是工厂模式）。。
说白了，就是你要把你系统里面“重要的”东西挑出来，让它在“设计图纸”上可见，而不是分析完代码才能看出来！
显性化
重要的东西找到了，如何显性化呢，其实就是“命名”。名不正则言不顺，名字反映了职责，名字也让领域专家、架构师、程序员对“同一个东西”进行讨论，而不是“牛头不对马嘴”。
形成体系
找到了“重要的东西”，“命名成构造块”，接下来就是通过某种结构，把这些“构造块”组装起来，成为一个整体。这就成了某种“方法论”！
建模的层次
不是说做业务分析才有建模，即使没有任何的业务建模，你就直接写一个超大函数，里面包含所有代码，这何尝不是一种“建模”呢？
只不过这种“建模”的构造块太小：加、减、乘、除，if-else，for，while。。这些就是这种“建模”方法的构造块，并且这种方法，当程序员的都尤为擅长。
再远一步，我在这写文章和你沟通，何尝不是一种“建模”呢？这里建模的“构造块”就是那常用的3000多个汉字和标点符号，构造规则就是”主谓宾定状补“。
通过上面的分析，我总结出如下的建模范式：
把这个范式，应用到不同的粒度，得到下面的图示
(1) 自然语言建模
构造块：常用的那几千个汉字（或者英语的10万单词）。。
语法规则：主谓宾定状补
(2)计算机语言建模
构造块：加/减/乘/除，if-else, for, while..
语法规则：程序员最熟悉，此处就不说了
(3)过程建模
构造块：函数
语法规则：整个系统描述成一个个过程，每个过程通过函数的层层调用组成
(4)对象建模
构造块：对象
语法规则: 整个系统描述成对象与对象之间的关系
(5) DDD领域建模
构造块：实体/值对象/领域服务/领域事件/聚合根/工厂/仓库/限界上下文
语法规则：就是“构造块”之间的联系（不是很明显，这个需要深入研究。也正是DDD难掌握的地方）
最后
本文试图跳出各种软件方法论的“框框”，从一个旁观者角度去审视“建模”这个最最基本的东西，希望以此成为大家理解DDD的一个线索。