思考模型设计

做了很久的模型设计一直没有好好总结。

模型主要是为了更好的抽象业务，将业务原型通过模型描述出来，这个模型一般是我们所说的领域模型。领域模型应该就是站在业务角度从专业业务角度建模出发思考。一般场景下领域模型与我们使用的技术模型差距还挺大的。领域模型到技术模型过程中必然是经历分析模型的过程，由标准的业务领域模型逐步转化为技术实现模型；在转化的过程中我们可能会遇到一些难点，也很有可能推翻领域模型重来。最终衍生出了我们的技术实现模型。
最理想的情况下是领域模型就是我们的技术模型，领域模型一定是业务原型的抽象。
从领域设计驱动的角度来讲，是推荐领域模型设计与分析模型、技术模型设计融合为一个整体；从而设计出来的领域模型是必然符合技术模型的从而加速模型的产生减少缩短了模型产生的周期，减少模型产生的迭代次数都是可能的。

上面说了这么多好像也没有讲明白如何设计模型，只是分析到了有业务模型到技术模型的必然过程，推荐用基于领域模型驱动设计来提高模型抽象与设计的效率。

上面也讲到领域模型是业务原型的抽象，所以领域模型必然是基于业务专家抽象及规划出来的。所以领域模型的设计必不可少的是业务专家。业务领域专家更偏向于业务的分析与抽取，而不关心技术实现相关的。所以基于领域驱动设计的方式必然是需要技术专家与业务专家的结合。并且技术专家也是需要对于这块业务掌握的很熟悉并有一定深度。所以领域模型驱动设计对于设计人员要求都是比较高的。

互联网的业务发展极其迅速，如何来让模型适应这种变化；是非常大的挑战。非常羡慕哪种传统行业业务的规划及标准化必然带来了模型的稳定性及标准化设计。

目前我对于技术模型实现上主要是这么干的，有核心领域模型与业务核心模型是一致的。但是领域模型在现有业务使用常见基本上没办法用起来，所以基于领域模型基础之上在扩展细化现有场景下的子模型作为技术实现模型，并规划了细分行业下的技术模型的扩展方式；通过规范化及标准化附属业务子模型的管理。其他很多附属业务子模型更多的考虑的是通过组合包装试图模型的方法让子模型更好的扩展方式及更偏向使用场景的试图模型包装；避免大而全的模型出现。

好的模型设计最终一定要满足几个方面：
1）体现核心的业务抽象、标准化业务逻辑的封装
2）简单的的业务扩展方式
3）核心模型的稳定性及较少的升级、维护、管理成本
4）模型的使用的易用性及可定制性
5）有效的区分业务模型、试图模型、数据模型等等所在场景。