有个著名的“第一性原理”，很多人因为“马斯克”知道了这个原理，虽然这个原理不属于“马斯克”但他应当是最著名的代言人，如果没学过强烈建议学习学习。虽然也有人以这个名字出书，但是这个原理本身非常简单，总结一下就四个字“本质思维”，这个本质思维可以单独写一篇文章总结。
问题：什么是模型映射设计方法？
在软件架构设计过程中，先从表象的各式各样的设计图中脱离出来，按照“本质思维”方式推理架构设计的本质是什么，架构设计最本质的事情就是研发人员理解用户需求并使用专业技术进行设计的过程，在设计过程之后是研发过程进行编码落地实现，所以在设计过程中很少设计具体的编码。
乱花渐欲迷人眼的设计图
设计本质
架构设计=架构+设计，架构主要是软件组件或构件，设计主要是理解业务融合架构的过程。
首先介绍两个概念“模型”和“映射”。
- 什么是模型，模型在MBALib百科中的解释是“模型是指对于某个实际问题或客观事物、规律进行抽象后的一种形式化表达方式。”，简单说就是抽象一个结构化的展示方式。
- 什么是映射，数学中有映射的概念，指两个元素的集之间元素相互“对应”的关系，类似两个集合A和B之间的映射可以记为A→B。
然后为什么需要这两个概念。 架构设计的本质是“研发人员理解用户需求并使用专业技术进行设计的过程”，怎么算是理解用户需求？怎么算是专业的技术？用如下专业术语定义业务模型和技术模型，建立共享Context上下文。
- 结构化抽象的业务模型，用户需求
- 结构化抽象的技术模型，技术方案
最后设计是什么，设计就是“业务需求→技术方案”（业务需求映射到技术方案）的过程。
映射设计过程
用户需求
什么是用户需求，做过软件研发的同学都接触过用户需求，那么以下需求描述（文字/视觉/流程图/视频/Word）中哪些描述方式属于合理用户需求？
用户多种需求描述
以上用户需求描述的方式都属于合理用户需求，但达不到用户需求抽象模型的层次，用户需求其实有一个通用模型就是敏捷迭代中的UserStory，UserStory其实就是一个场景的描述，包括什么人想做什么以便达到什么目的，UserStory抽象公式化的定义如下
UserStory - 作为[角色]，我想[做什么]，以便达到[什么目的]
这种定义就是结构化的用户需求模型。
技术方案
什么是技术方案，如果软件同学写过“技术方案文档”一定会印象深刻，能够深刻感受到当年写作文时的理屈词穷。明明一个很简单的技术事情既要用浮夸又要用规范的文字描述出来；技术人都有技术思维，什么是技术思维？某一维度上技术思维是化繁为简的思维，就是通过各种方式方法将复杂性问题结构切割简单化处理。因为单纯技术思维与常见技术方案设计有一定冲突，所以这里我们用一种简单方式定义技术方案，借鉴云计算的三层架构及三类资源进行技术方案的描述。
三层云计算技术
这种定义就是结构化的技术方案模型。
模型映射
因为单纯的文字总感觉力量不够，所以想借用一些高大上的事物。这里借用数学的函数映射概念，寻找一个函数f，按照这个函数f设计能够提升一些用户需求转变为技术方案的效果。
用户需求 → 技术方案，f(用户需求)=技术方案，f为部分映射函数
结论先行，映射函数f从业务需求出发，首先抽象业务模型得到用户故事，然后经过多层推论设计，最终映射到专业技术上，整个过程期望得到一个优化的架构设计结果。
重点映射环节
上面每一个环节都需要在理解用户需求的基础上，结合技术方案进行设计，各环节简单说明如下。
| 环节 | 设计方法 | 关注点 |
|---|---|---|
| 用户故事 | 使用UserStory结构化描述用户故事，作为[角色]，我想[做什么]，以便达到[什么目的]。 | 用户场景全面性 |
| 技术故事 | 在用户之外增加“技术角色”完善用户故事，技术故事主要侧重点在技术约束上不应当替代用户故事，比如“作为[信息安全员]我想[单向加密登录密码]以便[防止用户密码泄露]”，用户故事+技术故事形成完整的业务及功能场景描述。 | 技术约束条件 |
| 领域模型 | 通过领域驱动建模或者数据建模方法，抽象业务实体或数据模型，此模型不应当完全映射为数据库表模型。 | 业务变化性 |
| 开发架构 | 基于场景+模型划分模块、子系统、系统，在这一环节就可以使用分层架构等设计方法组合架构构件 | 高内聚低耦合 |
| 部署架构 | 结合软件系统的物理环境，包括主机、网络、终端等组合物理部署架构设计 | 物理硬件优缺点 |
| 重点过程 | 对于业务流程中比较复杂的业务过程，采用过程视图等方式进行细化确定 | 复杂业务共享 |
软件架构设计又称之为复杂性设计，复杂就复杂在除了业务和技术两个双链条和上面几个重点设计环节外，还需要考虑非常多的“约束”条件，下面是整理的常见约束条件。
非功能性约束
回答：模型映射是从用户需求模型出发映射到技术模型。
模型映射设计方法
复杂分析
架构设计的复杂性除了上面提到的，还包括技术的不确定性、团队的稳定性和项目的阶段性等，比如在面试过程中被问到的一个问题：如何避免宇宙变异粒子导致的一个bit传输数据置反？设计过程中也需要考虑团队是否能够支撑设计结果，比如3人的研发团队使用微服务架构是否合理？当然这个问题没有标准答案。
软件复杂性分析
