我20年的to B 企业软件生涯，服务了众多的大中企业，最值得写写的是成功改造了蒙牛的客户营销系统，支撑了蒙牛3000家经销商从100亿到500亿年营业额。这当然是一个企业软件应该做到的本分要求，其实这也不容易，因为就这样的本分要求很多软件也实现不了，当年在企业ERP圈流行一句话：“企业不上ERP是等死，上ERP是找死。”可见企业ERP有多难，又何况是蒙牛这样业务快速发展，管理水平很高的企业呢？

在这二十年中，软件思想架构也快速发展，最近新出来很多的低代码平台、数据中台、微服务架构等，仔细想想，原来在2006年我给蒙牛构建的系统中，早已通过小米加步枪的模式实现了，所以这部分才是最值得书写一番的。

这些软件架构思想都不是凭空来的，而是需要解决软件的实际问题，这些问题不是蒙牛独有的，而是整个软件业面临的非常痛苦的普遍问题，先看看蒙牛的系统当时面临的紧急问题。

蒙牛的系统当时叫做网络分销系统，解决了常温、低温两大事业部的生产库存销售运输配送应收等业务，解决了总部和3000家经销商自身的业务和它们之间的业务协同。那时候互联网刚刚兴起，2000年时候的互联网第一次热潮，人们用互联网来传递资讯，中国诞生了第一代三大巨头，新浪、搜狐、网易。资讯类网站比较简单，都是静态的页面，而网络分销系统却用网页模式实现了桌面软件才能实现的需要复杂界面控制逻辑的企业管理软件系统，虽然别扭，但是这样的系统解决了桌面软件系统的最大痛点：信息孤岛问题。2000时候，中国经济已经开始准备腾飞了，企业规模越来越大，全国性的经营，跨地域的分子公司很多，如何整合这些分子公司的业务系统，实现业务系统的协同，犹如蜀道难，难于上青天。

网络分销系统解决了这个问题，所以，广受各大企业的欢迎，当然上了系统之后，解决了一个痛，又带来了新的痛。蒙牛的系统当时面临这三个急需解决的问题，第一，性能问题，系统响应速度慢，经常堵塞导致系统没有响应，对于蒙牛这样的快销品行业，需要一个二十四小时的在线的系统。第二、网络分销系统这样的基于时髦的BS架构的系统，是运行在浏览器中的，这就出现了浏览器不兼容、操作系统不兼容等常见的应用问题。第三，系统扩展性不强，无法支撑蒙牛先进的管理，蒙牛还有众多的需求没有实现，业务快速变化，新需求很多，如何快速在系统中实现，是个非常大的问题。

蒙牛这个系统的二次开发和维护是另外一家公司在做，他们解决的非常不理想，所以，后来找到我们，我们不一样，因为我们是这套系统的开发者之一，我还是曾是这个产品的开发经理，我们对这个系统很熟悉，在第一次简单合作后，客户非常信任我们，展开了长达十五年的合作，还开发了人力资源系统和生产计划管理系统，后来重新给他们开发了客户营销系统。

因为我们熟悉系统，所以，问题的分析和解决能直达问题的本质，对问题的解决方案，暗合了十几年后的软件发展潮流。

DLL黑洞到数据中台

蒙牛的网络分销系统，采用的是微软的三层技术体系架构，中间的业务逻辑层是用VB写的DLL组件，这个组件应用有一个致命的问题，叫DLL黑洞，就是更新DLL后，经常莫名其妙的没有响应，必须得关服务器，然后，清除注册表里所有的相关注册项，这对需要随时在线的系统来说，当然无异于是个灾难。而且，因为业务逻辑在DLL里，所以对DLL的修改是个经常性的操作，只要有修改，就得更新，每次更新又非常麻烦，要停止系统一两个小时以上，这几乎是没法接受的。

所以，我想了个办法，绕开这个问题，展开第一性原理思维，DLL组件的目的，是为了在前端和数据库之间交换数据，并做业务逻辑的计算，问题是数据库也可以做业务逻辑计算，为什么不把业务逻辑计算放到数据库呢？DLL处理业务逻辑还不是强项，这也是现代的低代码平台的痛，解决不了复杂的业务逻辑计算。

解决这个问题要标准化DLL组件业务，抽象出来， DLL组件就处理两类业务，第一是需要事务控制的增删改操作，第二是不需要事务控制的查询操作。于是，我的数据中台就出来了。

只需要一个DLL组件，这个组件除了安全控制外，就两个对外方法：

1. DoOperation：需要事务控制的增删改操作。
2. DoQuery：不需要事务控制的查询操作。

为了统一操作，还需要解决一个问题，参数问题，以前的逻辑一般是参数个数不变，当需要增加字段时，就必须增加参数，这也导致DLL组件频繁修改，可扩展性非常差，比如最简单的增加一个字段，从修改代码到部署成功，可能需要几天的时间。为了解决这个问题，我标准化了参数的问题，依然是采用第一性原理思维，一个DLL组件的方法，无非是解决两个问题，接收数据，逻辑加工数据，然后返回数据，所以，我用XML格式的字符串作为参数形式，那么一个组件的参数就抽象成一个入参一个出参。

1. inParam：传人参数，
2. outParam：传出参数。

这样，我的数据中台就完成了，一个组件两个方法，每个方法两个参数。后来阿里推出数据中台概念已经是十来年后的事情了。

我这个数据中台模式，从开发设计好后，十多年从来没有动过，我的团队也就不需要组件开发人员了。

高度抽象的中台，需要微服务架构

原来系统的模式，是多数据库模式，一个分子公司一个数据库，这也算是一种粗放型的微服务架构，比以前的单数据库模式先进多了。现在由于中台高度抽象，变成了两个方法，业务逻辑处理放到了数据库里，就把业务逻辑封装到数据库的存储过程里面，一个存储过程实现一个业务逻辑，这是我们微服务架构的微服务单元。

存储过程为了适配高度抽象的中台，设计了两个总存储过程，doOperation和doQuery，同样也要支持接收xml数据格式的参数，在这两个存储过程里实现微服务的分发。

这样的中台和微服务架构，带来了生产力的极大提升，解决了维护的超级大难题，我这个系统实现了热插拔能力。维护这种系统一个超级大难题，是定位业务逻辑问题，看看原来处理这样的问题有多难。

如果面对这样一个问题：客户说我这个销售数据不对啊，怎么办？

程序员要解决这个问题，需要重现这个问题，要重现这个问题，需要数据，很多时候都是这样，我测试环境没有问题啊，在你那里怎么就有问题了？于是，提了一个要求，把你数据库拿过来我看看，刚上线的时候可能还没有问题，如果上线几个月后，客户数据库一般就是数G或数十G，那时候很多还是拨号上网年代，怎么传递这么大的数据？

我的这些架构轻松解决，在客户的生产系统里，直接在生产数据库里，复制一个微服务的存储过程，直接开始调试，原来解决一个问题可能需要数周，现在几分钟搞定。

所以，我的团队不需要专门的服务人员，开发人员全部搞定，除了服务蒙牛的3000家经销商，还有我公司的其它十来个客户，都是大中型企业。

好的模式产生更高的生产力。

高扩展性的低代码平台

三层体系结构分为展现层、服务端层和数据库层，服务端层和数据库层都高度抽象化了，剩下就是展现层了，展现层把所有的应用分类，最后抽象出两个基本组件，编辑卡片和列表，企业应用一般都是数据列表，单据和统计报表，数据列表和统计报表比较类似，都是查询条件卡片和列表数据，查询条件卡片是可以编辑的卡片，单据一般是主子表模式，表头是编辑卡片，表体是列表，所以核心就是编辑卡片和数据列表，抽象出两种页面：列表页面和单据页面。

在重构系统时，通过xml配置文件的模式，配置列表界面和单据界面，每个界面基础的界面控制逻辑都是默认包含了，有特殊行为的再单独配置一下基本就能完成任务，由此实现了一套低代码的搞扩展性系统。在用这个架构给蒙牛开发完成人力资源系统和生产计划系统后，就基本完善了。在2009年用此平台重构蒙牛的客户营销系统时，只用了一个普通程序员四个月的时间就完成了开发测试任务，达到发布标准。

这套系统用了微软 DotNet Framework技术架构，客户端是winform，服务器端是webservice，数据库是MSSQL，程序员只需要掌握简单的C#代码，会配置xml文件，会写sql script，就可以开发了。后来还开发了医药流通行业的ERP和手机连锁专卖店的系统，都是一个普通程序员完成的。

BS应用的本质

那时浏览器应用刚开始流行，软件的主卖点是BS模式，就是基于浏览器的系统，界面都是网页的，解决了以前应用的一个大问题，就是重新部署和更新的问题，还有认为无论在那台机器上，只要能上网，打开浏览器，输入网址，就能用系统。

但是其本质是想减轻软件厂商的维护工作量，对于企业来说，需要的只是一个基于Internet的系统，能打破传统局域网系统的信息孤岛，而且，企业内部系统，员工一般都在固定的电脑上工作，并不需要随便那台机器上都能应用，后来发现为了安全性，反而指定员工在固定的公司内部设备上才能用公司的应用，BS模式反而不好控制了。

另外，由于浏览器厂商很多，系统为了适配各种浏览器，反而增加了开发工作量，也因为浏览器适配不全的问题，经常出现很多错误。

最重要一点是，企业应用一般都需要打印，那时候基于安全性的考虑，浏览器对打印的支持很弱，满足不了企业级票据打印的要求，所以，只能开发一个ActiveX控件来实现复杂的打印功能，这又几乎变成了另外一个噩梦，后来展现层的一半问题，都出现在这个打印控件上。

原来的理想是打开浏览器就能用系统，这样的理想很丰满，但现实非常骨感，必须安装这个ActiveX控件才能完整的用系统，而安装ActiveX控件一般比安装系统程序更复杂，出问题更难排查。

现在很多银行的网银也是这样，电脑端一般都是通过网页打开，但是要安装一套特别复杂的安全控件，还经常出问题，这也是我弃用建行网银，全部用招商银行网银的原因，招商银行网银是独立的应用程序，和浏览器无关，非常稳定。

还是应用第一性原理分析，企业级应用要解决的问题是部署难，系统升级难的问题。针对这个问题，我们在设计展现层时，采用了轻量级安装程序，只有几百K，然后自动更新模式，解决了部署难和升级难的问题。独立应用程序的稳定性优势就非常明显了，我们系统的基础架构，十多年都没什么变化，支持windows xp 以后所有的windows操作系统。

智能手机兴起以后，App模式兴起，浏览器模式没有了，为什么在手机端的应用没有厂商推浏览器模式呢？因为复杂的系统浏览器模式实现不了，所以，PC上的企业应用还是该回归APP模式，我们早在十五年前就是这个思路了。

总结

企业应用持续发展，新的思想层出不穷，中台、微服务架构、低代码平台，甚是热闹，现在想想，其实我们早在十多年前就实现了，不过方式是比较原始的，因为我们没有底层代码的能力，只能利用已有的软件技术去实现，小米加步枪的模式实现了现代时髦的技术架构。

朋友公司上了某套低代码平台的系统，简单应用是比较快，但是涉及到稍稍复杂一点的业务计算逻辑，低代码平台就非常吃力了，企业级应用要求有多高？我们当年经常处理的问题是计算出的单价要保留六位小数，还不能有0.000001的误差。