业务建模的三种境界

一、背景

这个话题是突然间从脑海中闪过的，感觉有点意思，可以聊一下，类似于学习的三种境界。很多技术文章或者技术人都会有这三种境界，现在带大家感受一下。

二、建模的感觉

2.1 从需求中建模

软件开发人员最开始的建模过程或者建模之旅大概率是从需求里来构建业务模型和数据模型的。这种方式一定程度上表达了现实到软件模型的映射，但是由于需求经过产品和客户的转译，到开发人员这里会减少一些信息，所以只能直观的表达这个需求比较显示化的一些业务模型。有时候因为信息沟通或者统一语言的问题，到开发人员这里会经常产生需求变更的情况，或者刚要开始做或者已经快做完了才发现缺东西或者不合理。这种建模过程带来的收益其实不是特别大。

2.2 从其他人总结的模型中建模

另外一种大多数场景下的建模过程是站在巨人的肩膀上，有时候产品或者老板也不清楚或者不满意当前的系统能力，所以通常来说互联网的大多数系统其实在某一领域上从模型上来讲相似度也有一些，只是表达的方式不一样。
那么在建模过程中我们可以通过别人已经开放出来的基本业务模型和对应的业务场景帮助自己构建业务系统模型，这对开发和产品来说会省下不少时间，因为有了一定的参考才能更好的匹配自己的需求。这种建模方式很适用于已经探索过的领域或者正在探索的领域，所以建模落地之前和之后都可以更好的把握风险。

2.3 从现实中建模

很多时候我们能从现实问题学习到很多，俗话说吃一堑长一智。大家遇到的问题大多大同小异，因此没有统一的标准， 有时候同一个功能做出来的实现也有一些区别，因此前面两种方式虽然能解决90%左右的问题，但是实际上剩下10%是很难克服的。也就是说当存在一些于当前模型不匹配或者定制化需求之后这10%在前面两种建模和落地方案的时候会造成很大的改动。
​

从现实中建模其实也要求软件开发和设计人员更清楚模型和业务服务能有多大的灵活性和扩展性，方便支撑一个业务领域在长时间的迭代过程中不至于变形。因此技术人员其实也需要更多的业务敏感性，对相关的字段，模型关联关系，模型的设计等都需要有针对性的考虑。
​

当然这种建模方式在软件开发需求中很少用，可能有一些原因，我总结如下：

1. 软件开发者可能没有更多的时间或者没有机会去接触现实需求并尝试梳理构建模型
2. 软件开发者无法承担构建错误模型的成本
3. 从现实中建模需要更多的建模知识和能力

三、建模案例

3.1 美团外卖线路优化

关于美团外卖系统相关的资料网上也有很多，比如下面的链接内容：
https://mp.weixin.qq.com/s?src=11&timestamp=1641369344&ver=3539&signature=wWqcMW0u7imvvMrGHaTSSiqnnQdUkCnuk3trK4Voe7FatRsEcYDr9dJ3-5Joml*pZv350qczJk5GqKmJW60QECwp4KkiP1IeLnK8ysNGsNseA-YQso6lrQPlZYdlVe9W&new=1
很多时候解决一个复杂现实的问题其实会涉及到多个领域还要有深厚的技术功底，只有从现实中建模并进行数学量化才可以得到更好的模型。
当然上面的案例也还没有表达重点，之前看过一些文章说的是一些技术人专门去街头或者工厂农场等进行技术建模和落地，这种可能更接近于第三种情况。

3.2 仓储管理系统建模

这个项目是我最后一段实习经历和第一段工作经历主要维护的系统，因为刚毕业所以相关仓储领域的业务知识肯定无从谈起，那么对于仓储领域来说我的建模经历肯定就是从产品的需求文档上来，因此我们做了几个模块包括简单的商品模型，仓库，城市，库存，调拨，出库，入库等等。这些模型从数据库上看在后面的迭代过程中没有太大变化，但是从需求上看需求是在一年左右的时间变得很少改动直到下线。因此需求对于模型的冲击很小，这种建模方式在当时也可能是最合适的了。

3.3 权限模型建模

这个是我最近准备进行代码实战的项目，目前还在写一些方法内容进行填充，在进行落地实践的时候一方面会议了自己曾经做过的系统模型另外一方面也从网上参考了RBAC相关的业务模型，所以这种建模方式算是站在大佬的肩膀上按照自己的想法去构建了一个新的权限模型。

四、总结

据我所知目前建模的方法有好几种，有些是领域相关的，有些跟领域关系不大，但是不管怎么样，是哪种境界，建模就是对客观世界的理解和映射，所以了解和使用建模相关的方法工具能灵活运用就是最好的境界。