架构中保障交付关键动作之复杂度控制

复杂性和不确定性看起来是一码事情，其实差异很大：

• 不确定性是指问题随时间推移，发生了不连续的、不可预测的变化。
• 复杂性则强调问题或者解决方案，很难用几个简单的维度去描述。

那么如何控制复杂度呢？

第一，从问题域层面分解架构规划和交付方案。

具体而言，就是将整个架构活动按照问题域，分解成不同领域的子问题。然后在每个问题域，从粗到细一步步分解成细粒度的执行方案。

事实上，研发团队日常的任务分割往往也是按照问题域拆解的。所以你可以最大程度地利用日常已经形成的沟通协作机制，最小化交付风险。

假设我们在做一个大规模的电商系统内容化升级的项目，需要根据日常的垂直领域划分——流量、导购、搜索推荐、交易、资金、评价、商品、商家、服务、履约、物流等，把整体任务分配到各个领域中去。而各个领域呢，则会根据内容化的需求来决定各自领域的规划。比如流量领域，需要有内容承接部分的定制、投放、生成等。而履约和物流领域，则跟这个项目几乎没有任何关系。

当每个领域都完成进一步的方案细化后，我们可能会发现，流量、导购、商品、商家、服务等领域存在共性的模块，也就是内容生成和其他的内容操作。如果每个领域都各自开发这些模块，那就会造成大量的浪费。这个时候，可以把这些跨多个垂直领域的内容相关问题，组合成一个新的内容域。由这个新的垂直领域，来完成与内容相关的所有规划和交付，从生成到审核、编码、投放、播放、埋点、监控和分析等等。

第二，增加架构设计方案本身的结构性。

结构性，指的是贯穿企业所有软件实现方案的统一模式。反映在设计上，就是结构化设计（Structured Design），意思是不同领域、不同模块的设计是同构的。

如果所有参与方都采用微服务设计、响应式设计或者前端低代码设计。那么这种结构化的设计有什么优势呢？除了运维测试等方面的优势外，它最大的优势就在于未来的改动成本比较低。我们做架构永远都不是为了现在，而是为了未来。只有容易适应未来环境的设计，才能最大化企业的生存。

如果做电商化系统，那么我们可以把整个技术架构分成三层：业务层、中台和没有业务语义的基础设施层。随着我们对业务理解的深入，会发现，中台需要被分成两层——上面一层是业务中台，下面一层是数据中台层和共享技术层。这两个步骤都是水平切分的。

然后可以根据业务域，进一步把业务层的模块切换成多个垂直的领域，在每个领域内做再进一步的方案细化。虽然每个领域的商业逻辑有差异，但是它们使用同样的编程语言、微服务框架、测试框架和发布流程。这种企业层面上宏观的结构性，就是我们要追求的结构化设计。

需要注意的是，结构化设计的过程不是你这个架构师口头说说就可以了。这种宏观上的结构性，来自架构师与其他参与者在每个领域的决策上对结构性的追求。

事实上，许多架构活动的唯一目标就是提升企业软件架构的结构性。参加过技术栈统一、数据模型统一、全站埋点标准化这样的项目，它们的目标都是提升软件系统的结构性。可是，把一个混乱的系统重构成一个结构化的系统的成本非常高。所以我们应该通过日常架构活动的自律，来避免软件结构性的退化。可以这么说，任意破坏企业整体的软件结构性的行为都是可耻的！

当然，有些架构活动的首要目标是构造新的商业模式或者最大化商业价值。这种大的商业模式的变化，往往同时覆盖多个领域和软件架构的多个分层，而且时间非常紧迫。在这种架构活动中，想提升软件设计的结构性就比较难。因为这种项目对结构性一般是有破坏性的。

第三，按照多种方式分割交付模块。

分割交付模块的理念与小步快跑是类似的。比较常见的办法是分期交付，比如按部门、按领域或者按架构分层进行分期。

按部门或领域交付，意思是按照垂直领域分别完成架构项目的交付。按架构分层交付是指先完成最底层的变更，然后再逐渐往上。每一层的交付都保持向后兼容，从而最小化对上层业务的侵入。在未来的课程中，我们还会提到按最小价值单元交付的方法，指的是按照用户场景和需求划分来交付模块。

不论哪种交付方案，好处都在于整个交付过程跟一个松耦合的灰度发布的过程是类似的，以便你在小范围内试错，提前发现问题。另一个好处是降低联调和验收的复杂度。此外，我们开篇提到的不确定性和复杂度的问题，基本上都可以迎刃而解。

此文章为5月Day4 学习笔记，内容来源于极客时间《郭东白的架构课》，推荐该课程。