一次关于架构的“嘴炮”( 二 ) _架构

文章插图

强制遵循规范：通常会要求业务公共的组件逐渐下沉到基础组件层，但随着时间的推移，这个规范很容易被打破
需要成熟的团队：领域专家（对业务细节非常熟悉的角色）和开发团队需紧密协作，构建出核心领域模型是关键。但盲目尝试 DDD 往往容易低估领域驱动设计这套方法论的实践成本，譬如将简单问题复杂化、陷入过分强调技术模型的陷阱

迄今为止，用于商业应用程序的最流行的软件架构设计模式是大泥球（Big Ball of Mud, BBoM），BBoM 是“......一片随意构造、杂乱无章、凌乱、任意拼贴、毫无头绪的代码丛林。”

泥球模式将扼杀开发，即便重构令人担忧，但也被认为是理所应当。然而，如果还是缺乏对领域知识应有的关注和考量，新项目最终也会走向泥球。没有开发人员愿意处理大泥球，对于企业而言，陷入大泥球就会丧失快速实现商业价值的能力。

——《领域驱动设计模式、原理与实践》Scott Millett & Nick Tune

复杂系统熵增不断只要业务继续发展，越来越复杂就是必然趋势，这贴合热力学的熵增定律。
可以从两个维度来看复杂度熵增的过程：理解成本变高和预测难度变大。

文章插图

理解成本：规模和结构是影响理解成本的两个因素

宏大的规模是不好理解的，譬如：在城市路网中容易迷路，但在乡村中就那么几条道
复杂的结构是不好理解的，譬如：一个钟表要比一条内裤难以理解

当需求增多时，软件系统的规模也会增大，且这种增长趋势并非线性增长，会更加陡峭。倘若需求还产生了事先未曾预料到的变化，我们又没有足够的风险应对措施，在时间紧迫的情况下，难免会对设计做出妥协，头疼医头、脚疼医脚，在系统的各个地方打上补丁，从而欠下技术债（Technical Debt）。当技术债务越欠越多，累积到某个临界点时，就会由量变引起质变，整个软件系统的复杂度达到巅峰，步入衰亡的老年期，成为“可怕”的遗留系统。
【一次关于架构的“嘴炮”】
正如饲养场的“奶牛规则”：奶牛逐渐衰老，最终无奶可挤；然而与此同时，饲养成本却在上升。

——《实现领域驱动设计 - 深入理解软件的复杂度》张逸

预测难度：当下的筹码不足以应对未来的变化

业务变化不可预测，譬如：头条一开始只是一个单端的咨询流产品，5 年前谁也不会预先设计 Lite 版、抖音、懂车帝等，多端以及新的业务场景带来的变化是无法预测的。很多时候，我们只需要在当下做到“恰当”的架构设计，但需要尽可能保持“有序”，一旦脱离了“有序”，那必将走向混乱，变得愈加不可预测
技术变化不可预测，譬如：作为一个 JAVA 开发人员，Lambda 表达式的简洁、函数式编程的快感、声明式/响应式 UI 的体验，都是“真香”的技术变化，而陈旧的 Java 版本以及配套的依赖都需要升级，一旦升级，伴随着的就是多版本共存、依赖地狱(传递升级)等令人胆颤的问题。很多时候，我们不需要也没办法做出未来技术的架构设计，但需要让架构保持“清晰”，这样我们能更快的拥抱技术的变化

既然注定是逆风局，那跑到最后就算赢。

过多的流程规范反倒会让大家觉得是自己是牵线木偶，牵线木偶注定会随风而逝。

我们应该更多“强调”一些原则，譬如：分而治之、控制规模、保持结构的清晰与一致，而不是要求大家一定要按照某一份指南进行架构设计，那既降低不了复杂度，又跟不上变化。“强调”并不直接解决问题，而是把重要的问题凸显出来，让大家在一定的原则下自己找到问题的解决办法。

我们的打法我们的套路是：定义问题 → 确定架构 → 方案落地 → 结果复盘。越是前面的步骤，就越是重要和抽象，也越是困难，越能体现架构师的功力。所以，我们打法的第一步就是要认清问题所在。