本文围绕《架构现代化》一书展开，从“架构共鸣”的角度探讨了软件架构设计中的多个核心议题。文章通过八个方面——大泥团、独立价值、领域划分、概念设计、分类视角、领域厚度、全局与局部、脚手架——系统性地分析了架构演化中的常见问题与应对策略。强调了在复杂系统中避免代码混乱、明确权责边界、合理划分领域、建立共识概念、科学分类、理解领域复杂性、平衡局部与全局复杂度，以及架构活动的阶段性与可复用性。最终指出，架构现代化的关键不仅在于技术本身，更在于团队信任与工程卓越，推动“码农”向具备设计思维的“工程师”转变。
前言
近期看了《架构现代化》这本书，很有感觉，但是这些感觉是什么？可能只是一些共鸣或者感同身受，但是可以让人很安静，感觉到他人的认知深刻。为了更好地体会这本书，我还是将内容进一步延伸，从共鸣的切点出发，谈谈日常的一些感悟，更好地产生关联，吸收养分。
大泥团
即使开始有着“巧夺天宫”的设计，也会受到“演化”的影响。问题域在不停地变化，代码也需要不停地适应改变。如果没有结构设计，那么所有的代码都混在一起，将会形成一个“大泥团”。
历史上遗留不用的代码，也会出现在你的视野中，成为认知负担。同一个实现，要考虑多种链路的实现，工作量直接翻倍。所以我们需要一个能够隔离变化，支持“新陈代谢”的框架，把不用的，重复的，零时的等各种代码进行精简归一。如同免疫细胞抵抗外来的病毒入侵一样，是一个抵抗熵增的过程。
关于“技术债”的后果，研究表明：“多达 42% 的开发人员时间可能被浪费”。日常比较可惜的是，我们往往关注的是开发阶段的工作时间，这部分的时间其实增加的并不多；而前期沟通理解的时间成本，因为其较难定量分析，成为了大家的痛点“共识”，却很难论证。
为了进一步打破这个恶性循环，我们需要将视角更多地转移到编码之外，结合前期的链路理解、需求评估，事后的测试、运维、资损防护等角度，综合考虑“技术债”的成本。
架构健康度逐渐下降的恶性循环
独立价值
独立价值流是指能够对提供的产品进行负责和决策，权责一体。这样就像“包产到户”一样，大家更有积极性，干得好就能有更好的效果，更加轻松地完成任务。
权责一体，看上去非常简单，我们提供服务，然后对服务负责。但是在复杂的组织中，会出现复用的情况。有各种各样的平台，一个对客产品，是业务和平台共同融合的结果，甚至还有业务和业务叠加的场景。
这样的情况下，哪个业务最终对产品负责？平台是否有存在的意义？平台的存在是帮助业务更好的发展还是阻碍业务的发展？已经很难简单的回答，因为责任被细分和组装了，每个团队的定位和目标也开始各自演化，需要定期对焦对齐。
对业务而言，业务的叠加能够更好地促进购买利益点，打动消费者。但是也容易变成“大锅饭”，大家都往核心流量上靠，让本来不错的业务融合了过多想法，变得越来越复杂。同时，很多“低效”产品功能成了“自圆其说”的故事。耦合在一起后，单个业务的效率很难讲得清楚，只要不降低效率，遭到用户投诉，也是“睁一只眼，闭一只眼”，试一试又何妨，付出代价较低。
对于平台而言，如果没有前台场景，可能是一件不幸的事情，因为大概率做成纯粹的“技术产品”，难以满足业务诉求；如果有很多前台场景，也可能是一件不幸的事情，大家疲于业务交付，没有思考的时间，只是业务代码“下沉”到平台而已。
在整体的生态中，划分业务的范围，协调业务和平台的关系，确定各自的价值和职责，将会是一个长期动态平衡的过程。
独立价值流的四个关键特性
领域划分
领域划分是非常重要的事情，因为领域是对问题域的承接。将一个问题分解为子问题，确定边界，可以更好地通过协作的方式，汇聚大家的力量，达到分而治之的目的。但是领域的划分如何而来？
从问题分析的角度看，需要通过用户的交互案例，确定整个用户动线过程中的事件和结果。再进一步去对事件需要提供的能力进行分析，确定具体的任务。最后进行一些归类，设计出一定的边界和领域。
这个过程中，如果我们观察参与者和讨论方法的话，可能有一些疑惑：一是，谁来讨论和设计？二是，是顶层设计还是现状归纳和演化？
大家常见的策略是，空降架构师，然后带着各个团队TL，进行梳理和合计，向老板汇报，有点顶层设计的策略。这种方案偏移植行业成功案例，进行革新的意味。
日常发生频率更高的是，系统架构师基于日常问题分析和设计，通过日常专项，进行优化演进。在系统内会逐渐出现子领域的情况，但是很难跨越系统，拉通多个系统。
关于这个问题，我觉得理DDD领域驱动方面的“六边形架构”很有启发，六边形架构将领域作为抽象内核，将入口和实现都看成了周边环境和具体实现，实现了上下分层架构到内外抽象结构的演化。
同理来看，无论是顶层设计还是底层实现，都是领域抽象和划分的外部输入，没有鄙视链一说。比如：上面的设计觉得下面的太关注实现，下面的实现觉得上面的设计是天马行空，没有落地可能性。
这样的认知下，架构应该是架构师，团队TL，领域专家大家一起共创和共识的结构，案例的输入既有上面的用户动线，业务策略比较偏问题域的部分，也有具体的实现案例，反射出问题域讨论未考虑到点。所以，是一个抽象和现实互相映射的问题，需要大家一起找到巧妙的结合点。
利用事件风暴来协同识别领域和子领域
概念设计
“概念”设计如果说的简单一点，就是拉齐共识。这是一个看上去简单，但实际上非常困难的事情，难点就在于你需要拉齐多少范围的事情。如果只是“一家之言”，那么概念的讨论和收敛就很快，如果是需要拉齐很多的团队，就得进行讨论对焦，暴露冲突，探究初衷，求同存异，形成共识，收敛非常缓慢。
回过头来，从概念本身来说，它即帮助我们进一步分析问题域，又帮我们拉齐多团队实现共识，具有承上启下的作用。在架构活动中起着提纲挈领的作用。
对问题域而言，我们常常需要基于用例，设计业务活动和业务实体，然后内聚为领域和系统，提供服务。但是最开始的时候，我们讲的还是“人话”，并非计算机语言，将“人话”抽象标准下来，是概念需要解决的问题。就跟我们提“苹果”，到底是水果还是手机，其实很有歧义，所以概念定义也并非简单。
对具体实现而言，概念是具体实现的抽象，有一个映射的过程。但是由于粒度和场景的差异，在概念上，大家的粒度和理解并不一致。比如：概念上的商品，可能就是一个很抽象的交易标的，但是实现上，大家会认为是不是商家在商家后台发布的才是商品，在交易过程中衍生出来的一些服务，算不算商品就不好说了。所以，我们想抽象什么，要讲清楚我们的初衷，这样各个系统实现才能将实现概念进行分解聚合，从而进行对齐。
把话讲明白，的确是一件很困难的事情，因为概念的确定，除了基础的定义，还需要非常多的案例解释，进行判定，从而让大家更有感觉地体会其内涵。一个概念的说明，甚至可能都是一段讲不完的故事。
设计漩涡
分类视角
“设计就是在分类”，这句话非常巧妙地总结了架构活动。一方面，分类的底层就是我们的抽象概念，另一方面，这个类目树就是我们的映射对齐过程。
但是分类的困难在于，这个解不是唯一的。就像下面的图一样，我们可以按颜色进行分类，也可以按照形状进行分类。这时候，我们会发现，在某一个维度上，的确可以形成“正交”（互相不重叠），但是按考虑多个维度的划分后，就可能会出现归属不一和重叠的可能。
领域概念可以通过多种特征相互关联（耦合）
这对于我们的困难在于，我们应该选择哪些维度来作为我们分类的依据。或者说，我们需要寻找架构的关键要素，这些要素能够将边界切分得恰到好处，冲突不多。这里我们可能得进一步去分析每个待分类目标的产生原因，内部定义，和对外表现等更细的特征。
此外，我们不得不去认知“正交且完备”的架构期待是非常困难的，如果是概念层面，或许还能巧妙设计，恰好满足，但是实现层面，除非你是一维判定，那么就得接受，“不正交、不完备”的现实挑战。
我们的架构设计，其实也是追求大部分案例的抽象，也很难尽善尽美，定义一切。所以需要适当裁剪我们的目标和定位。
领域厚度
虽然我们日常划分了很多领域，这些领域看上去都是“平等公民”。但其实，其厚度是不一样的。因为不同领域的问题域，相关交互方的个数是不一样的。如果你只是内部模型，自己就能自治，那么压力并没有那么大，而且很领域领域架构演化；反之，如果你涉及相关方非常多，甚至涉及外部团队，那么领域的复杂性就很多，涉及很多概念的传递和共识，交付压力也会增加。
所以，当我们进入一个新的环境的时候，虽然看到的是系统复杂度，流程复杂度等一系列需要适应和学习的门槛，但是背后还是这个领域的“厚度”，其解决的问题需要涉及的相关方较多，概念的抽象和维护压力也很大。所以，领域的知识，是真正比较大的门槛。
于是，我们可以看到，同样按领域划分团队，大家人数和领域个数差不多，但是有些域的压力就很大，有些域就能够游刃有余。这背后还是“认知负荷”的结构。
在核心领域图上识别潜在的高认知负荷
全局与局部
我们得相信，“复杂”并不会减少，只是转移了。如果问题域是复杂的，那么我们的实现必然是复杂的。你要展示一个只读网页和做一个可提交数据的网页，复杂度天然就不会一样。在一个生态系统中，我们如果认为“全局”是一些列“局部”的组合。那我们得进一步看一下，我们关注的复杂度是哪些部分。
像微服务一样，我们可以把服务拆的很细很多，虽然每个服务很简单，但是服务的链接和编排是非常困难的，链路变得非常长，可靠性也会打折扣，这就造成了“低局部复杂性，高全局复杂性”的局面。
反之，我们可以把很多领域和逻辑，放在一个大系统中，这样系统和服务就变少了，系统间交互变得简单，但是系统内又会是一团乱麻。造成了“高局部复杂性，低全局复杂性”的局面。
局部和全局的取舍度放在哪里比较好？ 我觉得领域是一个比较好的切点，领域是同类型任务的归类，可以较好地承上启下。但是领域又可以分为子领域，领域的“度”又在哪里，这又是另外一个问题了。正如之前所说的，问题并不会消失，只是问题的焦点发生了转移。
总而言之，在不断演化的系统架构中，寻求局部与全局之间的复杂性平衡，是一项很难实现的任务。这个“度”需要结合组织结构、历史积累、行业趋势等进行综合考虑。
平衡局部复杂性与全局复杂性
脚手架
如同“没有只升不降的波浪”，架构组织的某项活动也不会一直存在。架构现代化赋能团队（AMET）注定在完成了既定使命后会逐渐解散。因为某个系统或者领域在大的框架下，已经具备了自我按序演化的能力。这很类似造房子的脚手架，开始的时候我们会搭建，方便大家工作，搭建完成后就要拆除。
但是，“太阳东升西落，周而复始”，脚手架拆除了也会在其他地方搭建起来。架构的活动，并没有消失，只是进行了转移。只有背后的业务不发展，才可能出现消失，如果问题域是在演化的，组织的动态平衡就在不断发生，架构的活动就会生生不息。
不过，我们寄希望于能够过上“游牧民族”的生活，可以迁移阵地，还是不够的。因为这样的过程，我们还是需要可以“沉淀的部分”，这是架构活动本身重复的抽象，是“架构”的“架构”。如果你一直拆脚手架，一直搭脚手架，至少得知道下次如何搭得更快，找到规律和窍门。
随着组织技能提升，AMET 的参与度降低
总结团队
无论之前的技术共鸣有多么“有感觉”，我们还是得回到我们的基石：就是我们的系统，以及日常的编码。
架构活动最后追求的基石，还是“卓越工程”，同时，我们期望“码农”真正走向“工程师”，不是一个资源，而是能够激发新的想法的，有设计思考的创新个体。
“如果问现代化改造中决定成败的关键是什么，那么答案是信任，来自高层领导对工作团队的信任，反之亦然。”这个信任的基础，不仅是因为相信所以信任，更是“言之有理，言之有物”，自然而然的信任，是基于事实推演的一个方案认可，而非“纸上谈兵”的个人与情怀信任。
团队介绍
本文作者 天未，来自淘天集团-交易平台技术团队。团队主要从事交易链路交付、平台治理工作，在交付工作中，抽象和建设横向产品能力（如：预售、电子凭证等），团队关注业务架构、DDD等理论与实践，致力于高效、稳定地实现业务接入，并抽象赋能。
¤ 拓展阅读 ¤
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
