软件系统理想主义之殇

对于软件系统工程治理方面的原则和思想，一个高级工程师就可以拿出一箩筐理论。复杂度治理的方法论和设计原则可以侃侃而谈到天亮。

软件系统治理可以围绕三个层次展开，底层代码面向对象，中层组件内聚沉淀，高层工程边界清晰。于是治理的思路围绕于面向对象治理，面向组件治理，面向工程治理。

整个治理的原则以领域设计驱动为底座，围绕限界上下文，核心域与非核心域展开，以六边形架构风格为编码模式，做好适配和防腐。

领域驱动可以分为战略和战术两个层面，大部分系统以领域驱动思想做好战略控制就可以了，过分强调战术实施，一不留神变成了系统未来扩展的掣肘，毕竟谁也不能看见最远的未来，能做的就是沉淀那些该沉淀的，拿不准吃不透的东西，做好扩展不制约发展就可以。

做系统设计最忌讳的就是想一口吃个胖子，谁知道胖子明天有什么想法，说不定这个有追求的胖子想减肥呢？

胖了瘦了都还好说毕竟只是形体的变化，人有精神层面和肉体层面的区分，软件系统也一样。长成什么样，具备哪些功能这些是肉体的表现形式，还有一部分精神层面的东西，比如系统的价值观。

什么是软件系统价值观呢？举个例子，我是一个平台化系统，对外支持的能力以开放接口方式实现，到这块听下来还没什么问题。

比如如果一个接口，他的能力是“发券”，就是各个前台系统调用这个发券接口去丰富和实现了这个前台系统一个发券的能力，如果这个接口包含发券规则参数，比如是否门店新老客，成本承担怎么分配，发哪种券类型，以哪个渠道发券，可以发多少张，一个用户可以领多少张。

整个接口入参70来个参数，这种接口怎么让业务方使用呢？不是难为人家吗。当然可以说我是平台化系统，需要具备通用能力，这个接口够通用了吧，70个参数你可以按需组装，总有一款适合你。

以上是一种软件系统价值观，时间久了系统设计细节中包含大量类似的价值观功能和代码。

另一种的价值观的系统设计原则是，“我是一个平台化系统，我的根本价值在于沉淀业务能力，可以实现前台业务的快速接入，以实现商业化试错”，所以其对外的沟通逻辑是，脏活累活平台做，你只需在我管理系统做好业务配置，拿走一个uuid，前台系统请求时您带着，您就可以放心的使用“发券”功能了。

你看看这服务态度，让业务方舒心，让甲方满意，这种价值观谁不喜欢谁不爱。有人说那这样，我中台系统不是越来越乱，越来越难以维护了吗？那这个关人家前台系统什么事，系统是有边界的。

关于边界这个问题是程序员经常被“诟病”的一点，程序员习惯了面向对象，业务系统边界，因为一整套软件设计思想都是基于“边界”而展开的，也是很多设计思想和设计模式的前提，只有有了这个前提我们才可以确定说的是一个问题域，而不是聊叉劈了。

但是程序员“边界”为先的思维久了，容易脱口而出“这不是我的问题”这句话，你细品你是不是说过类似的话，但是不要担心，这说明你是个好程序员。但是下次要注意说的对象是谁，如果是不太懂技术的，他可能认为“这小子想逃避责任啊”，你说冤不冤。

总之系统设计的很多原则某种程度上还是基于一个理想的土壤上去讨论的，比如都不是工作中可以真正接触到的“图书管理系统”“学生管理系统”。以至于一讨论你就认为它对，整个背景简直是为这个设计模式设计思想而生的，进入了一种陌陌遇见高富帅，大妈遇见贴心保健品销售员的模式，来了一次从内到外的软件设计pua。

我们大多时候过的最多的还是那种，柴米油盐波澜不惊的软件小市民生活，并不是天天重构系统，也不是天天拆分微服务，能认识到的无非就是任何系统做了久一点时间都会有以下问题：

1. 难以保持清晰的架构，虽然都想极力避免问题蔓延，但边界模糊乃至冲突的趋势不变；

2. 代码冗余，简单粗暴的写法肆虐；想重构却只能一天拖一天，直到系统庞大臃肿也不得；

3. 程序员离职入职，代码交接一茬又一茬，其间还有不同代码风格交混，缝缝补补又三年；

4. API 越来越多，既有模块谁都不敢轻易乱动，也没有多少人搞得懂来龙去脉，后续需求基本以模块叠加方式增加，冗余程度进一步增加，功能越加交错；

5. 系统成了四不像，轮子造的像方形的，奇怪的是不管怎么捏吧，最后关头也都能跑得起来；

6. 做了三五年该系统开发的人，以此系统为蓝本，推出“如何设计良好架构的大规模弹性可扩展系统”的课程或图书。