“模型映射设计”中最重要的环节是什么？长年累月的迭代中如何做可扩展性设计？业务的变化性指的什么？
问题：什么是模型映射架构设计？
模型映射设计
“模型映射架构设计方法”是从业务需求出发，经过技术故事加持并通过逻辑推理抽象四个视图View，最终映射到专业技术上形成技术方案的设计过程，其中抽象业务模型为用户故事，抽象技术模型为技术方案。经过这样的设计过程能够得到全面性较好的架构设计成果。
模型映射设计方法
以上几个环节中如果挑选最重要的是哪个？不同阶段的同学有不同选择，目前认为“领域模型”是最重要的。因为领域模型向上承载着业务的抽象，向下作为技术方案设计的起点，起到承上启下的作用所以非常重要。
注：领域模型不仅仅是数据库表
业务vs领域
“业务”是每个研发同学都了解的词汇，研发最主要的成果是支撑业务运行。“领域”最开始是通过领域驱动设计了解的。在日常迭代开发中，经常提到业务逻辑、业务模型、领域模型，但是为什么没有领域逻辑？业务和领域到底有什么区别？
尝试分析下业务和领域的区别
- 业务 - 主要指行业中需要处理的事务，在软件中业务一般属于某个行业，比如讨论HIS（医院信息系统）业务时一般代指了医疗行业背景。
- 领域 - 主要指一种特定的范围或区域，在软件中一般是一个高内聚的模块或系统，比如HIS中的设备控制模块。
一个“行业”包含多个互联的“业务”，一个“业务”包含多个高内聚的“领域”。
1业务 — N领域。
领域模型服务
领域模型就是业务中多个模块或系统的高内聚抽象。《领域驱动设计》是一种领域模型的抽象方法，所以DDD是一种业务需求建模的方法，但是对于代码层面指导性较弱。
领域模型不仅仅是数据模型，它在数据库层面落地的是库和表，在代码层面落地的是Entity + Service，在设计层面落地的是视图View。
领域驱动设计
变化性
什么情况下不需要设计？在软件系统确定不需要持续维护的情况下不需要设计，只要通过码代码实现功能需求即可。
如果以上的逻辑是正确的，那么架构设计究竟设计的是什么呢？目前认为设计的是“变化性”，这个变化性包括“业务变化性和技术变化性”，这里主要讨论业务变化性。
举个例子🌰，一句话业务需求：远程发布图片新闻等资源到设备屏幕播放展示。一种简化的“领域模型”设计如下，抽象三个高内聚领域，包括：基础域、设备域、资源域。
领域模型原始设计
这个模型比较简单不赘述，假设有一天需要支持发布到非设备终端，比如微信群、邮件群组等软终端要如何处理？一是增加领域模型（增加复杂性）承载业务二是重构“设备域”（比较累）代码和数据库表结构。如果最开始有“业务变化性”思维方式，能够想到发布模型中的设备只是一种终端，那么最开始就以如下领域模型设计，是不是可以直接兼容本次版本调整。
领域模型优化设计
针对变化性设计是设计的基本要求，比如上面例子最开始设计时就将“设备”融合在“展示域”就是一种可扩展性设计，当然可扩展性设计很容易变成冗余设计。也许有同学会说这是产品需求的问题，最开始没有设想到非设备的发布需求，这当然也有道理，但是最终系统的重构开发还是要由研发同学买单。
行业开放模型
在业务系统的研发过程中，对领域模型有两个痛点如下：
- 产品持续迭代中领域模型反复优化重构，此问题主要是业务认知深度
- 同一领域模型在不同公司产品中不一致，此问题主要是缺少行业标准
比如所有系统都有的权限管理功能，已经有很完整的“RBAC基于角色的权限管理模型”，如果新系统研发直接基于RBAC权限领域模型就可以具有良好的可扩展性设计。类比逻辑推理，一个软件系统常见的“领域模型”能否有行业标准定义，再通过基于模型生成代码等辅助手段减少底层重复工作，理论上可以提升设计的质量和效率。
是否有可能整理一个软件研发标准领域模型仓库，类似于Maven代码仓库一样。比如抽象下面的标准领域模型，包含如下模型的软件系统可以直接使用。如果更进一步能打造行业深度领域模型标准（具体到名字字段），比如教育行业基础数据领域模型，相信能够促进行业软件发展减少重复和底下的代码建设，节省研发时间也是另一种延长生命的方式。
行业标准领域模型参考 | 行业 | 业务 | 领域模型 | | --- | --- | --- | --- | | 通用 | 人员组织角色 | RBAC模型 | | 通用 | 监控日志记录 | 用户行为日志模型 | | 通用 | 信息发布 | 发布模型 | | 通用 | 设备管理 | 设备模型 | | ... | ... | ... |
可扩展性设计 - 通过逻辑推理提前找到业务变化性并针对变化性做的设计。
