PS：本文有些杂乱无章，偏向于是个人的一些思考。
概括来讲，纵观各种语言，其语法成分汇总起来构成一个关键概念集合。—— Leonard Talmy
在先前的一系列云研发体系的文章里，我们一直在对需求、代码等各种软件开发元素进行抽象、定义、建模。随着，这个抽象过程的一步步深入，便发现我们似乎也需要对于建模这一件事，做一层抽象。
建模是一件非常好玩的事情，我们总是在不断也抽象、抽象、抽象，还有定义、定义、定义。随着我们不断深入软件架构的设计里，我们也会不断也尝试着一系列不同的方法，诸如于我的同事 @少个分号 在那篇《建模方法元模型：如何设计一个建模方法》一文里，对于不同建模方式进行了简单的介绍，并进行了相关的拆解和分析。
每一种建模方法都有自己的优缺点，准确性-时间花费-维护成本之间的平衡，同时还依赖于不同的系统类型，依赖于我们的经验。因此，设计并实践一种新的建模方法，并不是一件容易的事 —— 需要经过大量地试验和验证。
回到这一篇文章来，我的意图是想寻找建模方法的一些共性。正好，结合一些最近对于模型与概念关系的一些思考。
从人类语言到编程语言
回到《认知语义学》对于语言的区分上来看，根据指代实体物和物质所用词汇化典型形式的不同，语言可以分成两种主要类型：
- 事物主导型语言(object-dominant language)，倾向于使用名词的语言，大多数语言属于这一类型
- 行动主导型语言 (action-dominant language)，倾向于使用动词的语言。
从这种定义来说，英语一种事物主导型语言，因为它倾向于使用名词来指称物理实体可触及的物质性。将上述的人类语言与编程语言进行映射，我们就会得到现今主流的编程范式：
- 面向对象编程。
- ~~函数式编程（待定）~~。
PS：从含义上来看，行动主导语言与函数式编程的对比并不是那么贴切，只是从书中 GET 到一些灵感。其中的准确性，有待于后续进行相关的验证。
从相似度来看，两种不同方式的主导型语言，更像是两种不同的驱动设计范式：模型驱动与事件驱动。
模型驱动 vs 事件驱动
从维基百科上的定义来看，事件驱动的定义是：
事件驱动编程（英语：Event-driven programming）是一种编程范式，其中程序的流程由诸如用户操作（鼠标单击、按键）、传感器输出或从其他程序或线程传递的消息等事件决定。
而对于模型驱动来说，它发展得相当的完善，以至于可以变成一个工程分支：
模型驱动工程（MDE, Model-Driven Engineering）是软件工程的一个分支，它将模型与建模拓展到软件开发的所有方面，形成一个多维建模空间，从而将工程活动建立在这些模型的映射和转换之上。MDE的基本原则是将模型视为第一实体，将所有软件产物当做模型或模型要素。
从软件工程的角度来看，模型驱动已经相当的成熟 —— 我们可以从模型作为出发点，进而构建出围绕于系统的分层架构、边界等。与此同时，在采用领域驱动设计的方式时，它还能将事件作为一种辅助的输入方式，来帮助完善整个系统的模型设计。
PS：从这一个角度来看的话，我们也可以围绕于事件驱动，构建出一套完整的软件开发模式。回到人类用来的语言沟通本身，我们记录的是动词、名词等一系列的内容构成的句子，如果将句子看成是一个个的用例，也是蛮有趣的。与此同时，既然我们可以存储模型，那么存储事件也是可以的，至于是代码还是其它形式就是另外一个故事了。
再回到面向对象这一点来看的话，建模就变成了一件非常有意思的事。
建模“建模”：从概念到模型
回到我们所开发的软件系统里，其系统的核心组成部分是由一个个的概念所组成。我们对于系统的理解程度，在认知的意义上来说，也取决于我们对于这些概念的理解和使用程度。在系统的设计初期，我们只有些许的概念。随着，系统的演进，我们引入了越来越多的概念，并以自己理解的方式，组织起这些概念的结构。受《认知语义学：概念构建系统》一书的启发，我尝试性去去探索它们之前的联系。
从语义学的角度来考虑，如果概念在特定的概念范畴内形成模式，这些概念范畴可称为图式范畴（schematics categories）。图式范畴在更为广泛、完整的概念结构系统中类聚，这些系统就可称为图式系统（schematics systems）。顺便一提，从分类上来说，常见的图式系统有：
- 构型结构（configurational structure）。包括了可以由封闭类（可以代指为实体）形式表达的空间、时间以其他定性域内的图式结构或几何轮廓。
- 视角（perspectivs）。用于观察这一类实体的视角，它们也可以由封闭类形式来表达。
- 注意分布（distribution of attension）。由分配在所指对象或场景上的不同强度的注意模式组成。
在以模型为主导的软件开发系统里，它们多数是可以归属于构型结构的图式系统。如在实现软件系统时，会使用实体的方式来表示这些概念，其对应到代码上的实现方式是：模型。通过结合多种不同的图式范畴，可以有多中不同的软件建模方式，如领域驱动设计里，便结合了领域（domain）、界态（state of boundedness）等。
建模的方式：基于“事实”的软件建模
PS：对于事实，从语言的角度，可能使用纪实、叙实会比较合适。
所有的软件开发都是由朝着满足用户关注点的方向而驱动的：捕获用户的关注点，设计系统来实现这些关注点，以及测试系统是否滿足这些关注点。
再次的，我们再将镜头拉回，回到软件开发中，初步的看一看现今的一些软件建模方式。它们为了“标准化”，需要围绕于这些“事实”来构建出模型。
PS：这里的“事实”指的是客观信息，诸如于事件、用例、凭证等一系列不依赖于人经验的要素。起初，我尝试使用表征一词，它的定义是一种将客观信息进行转换后得到的符号系统。在某种意义上来看，使用“事实”一词也显得不是那么准确。
基于用例的建模：用例驱动设计
用例驱动设计是一种“古老”的软件工程设计方法。其中，用例（UseCase）是对一个活动者使用系统的一项功能时，所进行的交互过程的一个文字描述。用例分析法会通过如下的方式来设计系统：
- 寻找用例并详细说明它们。
- 设计每个用例。
- 设计并实现每个类。
- 测试每个用例。
在这个过程中，用例便是这里的“事实”，围绕于这个已知的“事实”，有经验的开发人员，也可以凭借于此来进行规范化的开发。
基于事件的建模：事件风暴与领域驱动设计
在领域驱动设计中，采用事件风暴来进行系统的设计是一种较为模式化的工程方法。其中思想的一个核心要素是：事件是系统状态变化的关键帧。事件风暴由三个主要的步骤构成：
- 头脑风暴，以识别领域事件。
- 识别事件触发器（决策命令）。
- 识别聚合（业务承载物）。
在这个过程中，事件便是这里的“事实”，围绕于这个已知的“事实”。有经验的开发人员，也能通过此来构建出合理的系统架构。
基于凭证的建模：履约建模
履约建模是一个比较新的建模方法，它基于凭证的方式来设计系统。其核心要素是：作为业务凭证，只存在创建，不存在修改和删除。关键步骤如下：
- 寻找合约上下文，明确合同的参与方；
- 寻找合同约的主要履约项，按四色建模寻找凭证；
- 对于主要履约项，寻找违约情况，设立新履约项，按四色建模寻找凭证；
在这个过程中，凭证便是这里的“事实”，围绕于这个已知的“事实”。有经验的开发人员，也能通过此来构建出合理的系统架构。
建模建模
从某种意义上来说，寻找这些“事实”的过程，便是系统状态的表征过程。
表征，是信息在头脑中的呈现方式，是信息记载或表达的方式，能把某些实体或某类信息表达清楚的形式化系统，以及说明该系统如何行使其职能的若干规则。
所以，围绕于这些“事实”的建模方式的步骤，可以抽象为：
- 基于可确定的 “事实” 确定状态（or 数据）。
- 借助模式来编排状态。
- 映射与过滤去除影响因子。分离变化要素，得到基本的概念。
- 精炼概念，得到模型元素与行为。
- 概念类聚。上下文边界划分
这个过程，类似于对数据的处理流程：collect-map-filter-reduce 等。
其它
模型，只是我们对于事物的一种映射与理解。本文只是初步对于建模的一些思考~，有待后续进一步完善。
