本来在酝酿一篇技术文章，关于 JAVA的低代码化场景与nutz的mapl util类的一些相关应用，写着写着就开始乱扯了。

保险中介企业，需要不停的跟上游各家保司公司或分发型平台对接，按正常发展节奏，一年对接十几家上游很正常，积累到一定规模的时候，系统中同时五六十家在维护的很常见，更大规模的分发型平台，维护工作的体量更甚。

这种对接场景，其中的开发工作可以粗略分为两部分，通讯、报文转换，按保险产品的生命周期还可以分为出单、退保、追踪回执回访、保全，理赔、续期续保等等对接子流程。

其实这是ESB即企业消息总线产品的典型地盘。如果能基于ESB做好底层架构，后续的开发维护也是挺轻松的，因为可视化配置特性，初次对接时业务流程等方面的知识沉淀更为直观化，后续的人员交接、优化变动，就可以看图说话。只是这不太符合很大一部分做外包的JAVA程序员的利益，甲乙方博弈的水太深，基于常规源代码形式应该能做到原子级把控，维护三方产品尤其还是没有源代码的，出事时就说不清了。

但是换个视角，诺大一套平台系统，几十个人维护还有点忙不过来，最后公司要撤掉所有乙方，由甲方自己三两杆枪接手，彼时这几位甲方人员的心态会如何？当然是越不需要动全套代码越好，不要“改动一小行，打包半小时”，微服务？不存在的，乙方早给你默默合成了单体应用。

做开发，似乎还是在乙方轻松。

总之，甲方，希望自己的IT平台或者时髦点叫数字化平台，既要又要还要，既要是稳态的又要是敏态的，还要是Bigger的。

这个问题的底层是

微观，
量子级别，算法，逻辑
原子级别，数据
分子级别，结构、语言、编码Coding
细胞级别，封装，面向过程、面向对象

中观，
砖块/BuildingBlock级别、技术组件，模块化、技术栈
架构蓝图视角：模式、企业架构
工程实施：软件工程、项目管理

宏观，政治经济文化