企业官网建设流程全解析

这几年做大型系统重构，我最深的感受是：真正拖垮架构的，从来不是某一个具体的技术选型失误，而是我们对系统整体失去感知。不知道哪一层在悄悄带节奏，不知道哪个模块的债已经堆到临界点，也不知道下一次需求变更会从哪里撕开口子。于是每次优化都是局部补丁，局部补丁又带来新的局部失衡，系统就这样一点一点走向失控。

我试图从各种架构方法论里找解决方案，最后反而在《易经》里找到了一个非常顺手的观察框架。这套框架我整理成了《哲学驱动式软件架构法》系列，这篇是系列中关于实践内容的第 2.6 版。聊的不是玄学，而是把易卦当成一张“系统结构图”来用：六爻对应架构分层，爻位是否“当位”对应职责是否清晰，爻变对应状态迁移与演进路径。这套方法不能替你写代码，也不能替代领域驱动设计，但它能在一轮轮架构评审、重构和演进规划中，给你提供一套系统级的体检视角和方法论支撑。

适合谁看？我建议以下几类人可以重点参考：被复杂系统演进问题困扰的架构师、技术负责人，以及那些自认为懂微服务、懂 DDD、懂各种架构模式，却依然说不清系统为什么会腐化的人。这套方法的价值，不在于发明新的架构组件，而在于让你在动手之前，先建立一张能够同时表达“结构现状”和“变化方向”的系统全息图。

1. 这套方法到底想解决什么问题：从架构失控说起

1.1 失控的表现：不是性能差，而是“改不动”

我先描述几个非常典型的架构失控场景，你大概率见过其中一个。

第一个是改动蔓延。明明只是改一个简单的业务规则，却要同时动五个服务、七八张表，外加两条消息通道。开发同学排期三天，其中两天都是在理清“哪些地方也隐式依赖了这段逻辑”。第二个是回归爆炸。每次发版都要全链路回归，因为没人能拍着胸脯说“这个改动只影响局部”。第三个是重构失语。团队想治理架构，但开会讨论时每个人对系统现状的描述都不一样，连一张大家都认可的系统结构图都拿不出来。

这些问题有个共同特征：它们都不是靠换某个中间件、引入某种设计模式就能解决的。因为问题的根源不是某个局部模块坏了，而是模块与模块之间的关系失去了秩序。而关系层面的问题，恰恰是很多常规架构方法论最薄弱的地方。

1.2 共同根源：我们一直缺一张“系统全貌图”

为什么关系会失去秩序？我复盘过很多次之后，得出的结论是：我们在设计阶段很少以“系统整体”为对象去思考。我们习惯从单个服务、单张表、单个接口出发，用自底向上的方式把功能堆出来，却很少自顶向下地画一张全局图，更少去追问“这一层的变化会如何传递到相邻层次”。

比如说，业务团队提了一个新需求，研发同学第一反应是“要加一张表”“要加一个接口”，这没错。但如果每次都只做这种局部响应，系统的复杂度和混乱度就会像债务一样复利增长。一段时间后，架构就会变成一团谁都不敢动的毛线球。我们需要一种工具，能同时回答三个问题：系统现在长什么样？哪些地方是稳定骨架？哪些地方正在剧烈变化？这三件事，恰好是易卦这个古老模型最擅长表达的。

1.3 为什么是《易经》：它本身就是一套系统模型

聊《易经》容易跑偏，所以我先把话说清楚：我关心的不是占卜，也不是命理，而是它作为一套“系统状态编码模型”的内在结构。

《易经》对“易”有三个层面的解释：变易、不易、简易。这其实是给任何复杂系统写下的三条公理。软件系统同样如此——需求在变、技术在变、人员在变，这是变易；但系统所服务的核心业务逻辑、关键边界、长期原则往往非常稳定，这是不易；而把复杂问题用尽量少的模型表达清楚，让团队能高效协作，这是简易。你看，这三条放在软件架构里，几乎可以逐条对应。

再加上卦象本身的设计：一卦六爻，从下往上构成一个层次结构；阴阳两爻排布出不同的状态组合；爻位之间有生克、承乘、应比关系；动爻意味着整个系统即将发生变化。这简直就是一个天然的“架构状态图”建模框架。去掉占卜外壳之后，剩下的是一套非常完整、内洽的系统观察语言。

所以在这套方法里，卦象不是用来“预测未来”的，而是用来“描述当下”的。你说的每一句话，都必须能翻译回系统里的具体结构、具体职责、具体变化，才算是有效使用。

2. 核心映射：卦象、爻位与软件架构的系统同构

2.1 六爻不是算命，是系统分层模型

我在实际使用中，最常用的一张映射表是这样的——把六爻从下往上对应到软件架构的不同层次：

这张表是我比较推荐的起点，但它绝不是唯一标准。不同系统、不同团队完全可以自定义映射方式，只要团队内部达成一致即可。但有一点必须强调：映射规则一旦定下来，就不要频繁改动，否则后续评审时大家各说各话，这套方法就失去了意义。

有了这张映射表之后，架构评审就变成了一件很自然的事：打开系统代码结构或者架构图，逐个层次问“这一层当前承担的核心职责是什么？它应该承担的职责是什么？两者是否一致？”这比笼统地讨论“这个模块好不好”要精确得多。

2.2 “当位”与“不当位”：架构职责的体检标准

《易经》里有个概念叫“当位”，指爻处在它应该处的位置。阳爻在阳位，阴爻在阴位，这叫当位，系统状态就比较正；反之叫不当位，系统状态就会有隐患。

我把它借用过来做架构体检：如果一个职责恰好落在它该在的层次，就叫当位；如果职责错位，就叫不当位。典型的例子有很多。比如业务规则被写进了存储过程，这在二爻的数据层里塞进了三爻的业务逻辑，是不当位；比如网关层堆了大量业务判断，该做转发的地方做了决策，四爻抢了三爻的活，也是不当位。再比如编排逻辑和业务逻辑混在同一段代码里，五爻的职责和功能被稀释，同样是不当位。

我做过一次真实的架构评审，系统表面看没什么大问题，但一按爻位梳理，发现订单状态流转的逻辑分散在数据库触发器、业务服务、消息消费端三个地方。这就是典型的职责不当位——状态流转本质上是一种业务规则，它应该内聚在领域层，而不是散落在二层和三层之间。

检查“当位”有一个很实用的方法：拿到系统里最核心的两三个业务流程，沿着请求路径从下往上走一遍，每经过一个层次都记录一句“这里做了什么决策”。走完之后，你会发现很多决策发生的层次，和它应该发生的层次，往往对不上。

2.3 变易、不易、简易：三条架构公理

把《易经》的“三易”翻译成架构语言，我一般这样说：

变易，对应软件系统的演进能力。系统一定会变，所以架构不能是静态图纸，必须内置应对变化的机制。版本化接口、事件驱动、特性开关、读写分离改造，这些都是响应变易的手段。一个完全没有变易容量的架构，等于把系统焊死在当前需求上。

不易，对应系统稳定骨架。每个系统都存在一些长期不变的原则：订单域的金额计算逻辑、权限模型的核心边界、数据不可变事件流，等等。这部分应该被设计得尽量稳固，并且作为团队共识写入架构文档。判断一个东西该不该属于“不易”范畴，可以问一个问题：“三个月后、一年后，它还会是这样吗？”

简易，对应抽象模型的克制。很多架构腐化不是模型太少，而是模型太多、抽象太多、中转太多。一个简单的业务动作被拆成七八个中间层，每层做一点点事，结果没人能说得清完整链路。简易不是粗暴地砍层次，而是“用最少的必要概念表达系统的复杂度”。

这三条公理可以作为架构决策的过滤网：任何方案下来，先拿三易过一遍——它能不能适应未来变化（变易），有没有守住核心稳定边界（不易），是不是用最克制的方式实现的（简易）。

2.4 阴阳是设计张力的两面

阴阳在软件架构里，代表着两种相反相成的设计取向。我做过一个更具体的映射：

有意思的地方在于：这两种取向没有绝对的优劣，只有是否匹配当前阶段。比如一个早期产品，业务方向尚不明确，强一致的事务模型反而会拖慢试错速度，这时候偏“阳”的最终一致、独立演进更合适；而一个已经进入成熟期的核心交易系统，稳定压倒一切，那偏“阴”的收敛策略就更合理。

架构评审的时候，我会把这些张力对逐一拿出来，让团队对每一项明确表态：当前系统处在哪个位置？目标是哪个位置？差距是什么？坦诚面对这种张力，比硬选一边要务实得多。

2.5 三重视角：错卦、综卦、互卦的多面评审

《易经》里有几个卦变方法，拿来当评审视角非常好用。

错卦是阴阳完全反转，相当于站在当前方案的对立面看问题。比如你现在用了“写多读少、强同步”的方案，那就逼自己反着设计一版“读多写少、异步化”的方案，再对比差距。这种视角能发现“我们是不是因为习惯了某种方案，而忽略了更优的选择”。

综卦是上下颠倒，把系统倒过来看。站在下游消费方的视角审视上游生产方：接口字段是不是够用？消息格式是不是难以消费？错误处理是不是不友好？我能看到很多系统内部自我感觉良好，但下游对接方苦不堪言，就是因为很少换到被依赖的那一侧去看问题。

互卦是取中间部分独立成一个新系统来考察。取出系统里最复杂的某一段流程，把它当作一个独立的系统状态机来分析：输入是什么？状态有哪些？迁移条件是什么？出口是什么？往往能发现隐藏在主干流程中的次生复杂度。

这三种视角不需要每次评审都用全，但作为一个“多角度检查清单”，它们比单看一张架构图更不容易漏掉盲区。

3. 实战：用卦象模型做一次架构评审与演进规划

3.1 先立规矩：为系统建立“架构状态表”

我在实际操作中不会一上来就谈卦象，而是先做一张“架构状态表”。这张表是整个评审过程的主干，相当于给系统建立一份结构化的体检档案。

这张表的好处是它强制每个人用相同的维度描述系统。填表本身就是一次低成本的架构梳理，而且可复现：下一次评审再填一张，两张一对比，架构的演化轨迹就出来了。

3.2 逐爻诊断示例：某订单中台的架构体检

我举例说明一下，这是我一个朋友团队的真实项目，我参与过其中一轮评审，为了描述方便，我把它叫做“某电商平台的订单中台系统”。这个系统负责下单、支付、库存锁扣、履约调度和售后处理，是一个典型的跨多团队复杂系统。

评审时，我们按六爻逐个诊断，当时的状态记录大致是这样：

初爻（基础设施）：系统跑在自建容器平台上，但环境配置漂移严重，不同环境之间的基础设施差异导致很多“在我本地是好的，上了测试环境就挂了”的问题。此外，基础监控覆盖不足，底层组件的变更历史也缺乏追溯。结论是不当位，变化程度高。

二爻（数据）：订单主数据采用分库分表存储，但状态字段被多个服务直接修改，没有统一的状态机入口。数据库触发器里甚至残留着一部分业务校验逻辑。二爻的职责被严重旁落，不当位。

三爻（业务）：领域层本应承担核心业务规则，但实际情况是，部分业务规则下沉到了存储过程，另一部分上浮到了接口层的 DTO 里做校验，领域层反而变成了“贫血的传参对象”。这是典型的三爻空心化，不当位。

四爻（接口）：网关层为了兼容多个渠道，堆积了大量业务分支判断，接口数量膨胀严重。每次新增渠道都要改网关代码，评审时我们发现网关是变更最频繁的组件之一，不当位。

五爻（编排）：订单履约流程里存在一个自研流程引擎，但流程编排和业务规则混在同一个扩展点里，导致很多人不敢动这个引擎。五爻的决策能力被“混沌化”了，不当位。

上爻（外显）：对外表现主要关注订单查询体验、对账单准确性。当时这一层整体稳定，但查询性能开始出现劣化迹象，且缺乏用户体验指标的监控，只能说是勉强当位，有隐患。

这轮诊断的价值不在于指出了某个具体代码问题，而在于用六个格子把系统当前的健康状态结构化了。团队第一次在评审会上对“系统究竟哪里有问题”达成了共识。

3.3 找出动爻：真正牵一发而动全身的那一层

六个爻位之中，有一个要标记为“动爻”。动爻不是最烂的那一层，而是“当前牵一发而动全身的关键控制点”。我一般用“变更频率 × 影响范围”来判断。

在刚才那个订单中台里，我们标记的动爻是三爻（业务层）。为什么不是四爻网关？虽然网关变更也频繁，但网关的影响面主要是接入端的逻辑，而业务层一旦错位，会同时向上污染接口层、向下污染数据层。状态流转规则散落之后，改一个规则要动数据库触发器、业务服务、消息消费端三处，影响面实在太广。把三爻识别为动爻，意味着接下来所有大动作都应该围绕“让业务规则重新回到业务层”展开。

找动爻有一个非常实用的技巧：把“最近半年的变更记录”按爻位归类统计一下。哪个爻位相关变更最多、牵动的代码库最多，哪个爻位就有可能是当前系统的控制点。数据说话，比感觉靠谱得多。

3.4 从当前状态到目标状态：三步走演进路径

状态表填完之后，再定义一个“稳态目标”：初爻稳、二爻聚、三爻实、四爻清、五爻明、上爻显。这个目标其实是一种架构愿景，每个词都可以翻译成具体的工程指标。

围绕这个目标，我们排出三步走的演进顺序：

第一步，先稳底（初爻）。统一基础设施环境，用基础设施即代码管理配置，补齐可观测性体系。为什么先做这个？因为底层不稳，上层做任何改动都像是在流沙上盖楼，根因很难排查。

第二步，再固本（二爻、三爻）。把订单状态流转收敛到统一状态机，清理数据库触发器里的业务逻辑，让领域层真正承载业务规则。这一步是核心，也是工作量最大的部分。

第三步，后清外（四爻、五爻）。网关层做接口瘦身，把业务判断下沉到领域层，编排引擎的扩展点重新梳理，让流程编排回归流程本身。

这个顺序很关键。很多团队重构失败，不是因为不做，而是因为从上往下改，先改网关，先改接口，结果业务规则还是散在下面，改完只是表面光鲜，过两个月又坏回去。所以我的经验是：从爻位的角度，永远是先修底、再修腰、最后修脸。

提示：如果你只对其中一两个爻位做治理，那不要用整套流程，只要把这个爻位当位状态修好就行。这套方法可以轻量使用，不是每次都要全量体检。

3.5 爻变推演：改动一个爻位，邻爻会发生什么

架构演进过程中，改一爻往往会牵连邻爻，我把这个叫“爻变推演”。比如我们决定对二爻（数据层）做状态机收敛，看起来只是把订单状态的修改入口统一，实际推演下来，影响会传导到三爻（业务层）和四爻（接口层）。业务层需要适应新的状态流转调用方式，网关层则需要去掉那些曾经为了保证状态一致而写的补偿逻辑。

推演的方法很简单：站在一个爻位上，向上和向下各问一遍“如果我这里变了，上面会受什么影响，下面会受到什么影响”。这种邻位分析比全链路分析轻，又能覆盖绝大多数间接影响。我见过太多事故，都是因为只改了自己那一层，没想到上一层会拿旧格式继续消费，或者下一层还会用旧状态做查询。

做爻变推演时，我会把结果直接补充到架构状态表的“行动项”里，形成一个完整的闭环：改初爻受二爻牵连，改二爻受三爻、四爻牵连，所有受影响方的负责人和改造项都列出来。这样演进计划就不是一张孤零零的任务清单，而是带依赖关系的系统变更方案。

4. 踩过的坑与方法边界：哪些场景不要用这套方法

4.1 把卦名当标签，是最常见的误区

我最担心看到的一种用法是：评审会在尾声，有人一拍桌子说“我觉得这个系统就是坎卦”，然后大家都沉默了，接着散会。这样用，等于把卦象标签化，什么问题都没解决。

我的建议是：卦名最多只能作为记忆钩子，绝不能代替逐爻论证。正确顺序是先填完状态表、做完当位判断、标记动爻、推演变动，最后如果一定要总结成某个卦名的意象，作为团队的记忆锚点，那没问题。反过来，先贴标签再做解释，就是本末倒置。

4.2 只画快照，不记录演化轨迹

这套方法很容易让人只关注“当前这一瞬间”的系统状态。但架构是活的，真正的腐化是一个过程。我踩过的坑是：第一次评审做完，状态表放在文档库里吃灰，半年后再看，系统已经坏到另一个方向去了。

后来我要求每次评审都必须保留上一版状态表，并且写一栏“相对上一版的差异”。这一栏特别能说明问题——比如二爻的数据层变化程度从中到高，但对应的职责描述并没有明显变化，那说明数据层的代码复杂度正在上升，而结构没有改善，这就是隐性腐化的信号。只有对比行为，才能识别出系统的漂移方向。

4.3 映射表不统一，评审变成鸡同鸭讲

如果一个团队里，架构师把初爻定义为“基础设施层”，某个技术组长把初爻定义为“数据库层”，那评审一开始就已经分裂了。这种问题我在跨团队评审时遇到过不止一次。

解决办法很笨但有效：评审前先把映射表群发确认，每个人都要对“初爻是什么、上爻是什么”点头。如果团队里存在多个技术栈的异构系统，可以允许不同系统使用不同的映射规则，但同一套系统的同一轮评审必须只有一个映射标准。

4.4 这套方法不能替代什么

我得把边界划清楚，免得有人拿这套方法去替代正经工程实践。它不能替代事件风暴去厘清领域细节，不能替代 DDD 去设计限界上下文和聚合边界，不能替代契约测试去保证接口兼容，也不能替故障演练去验证系统的容错能力。

这套方法的定位是“架构体检总览”，它适合回答战略性问题：系统整体结构是否健康，职责是否错位，演进重点在哪里。一旦进入具体的战术方案设计，还是要回到各家方法论中去。两套东西配合使用，效果最好；单独拿任何一套硬扛复杂系统，都会吃力。

4.5 和主流方法论如何配合

以我自己的经验，配合方式大概是这样的：先用事件风暴把业务域和核心流程理出来，这是“业务侧”的地图；再用这套六爻方法，把地图上的各个部件贴到系统层级中去，检查结构是否当位；然后用 DDD 的聚合和限界上下文来细化领域模型内部设计；最后通过可观测性数据持续校准每个爻位的健康度。

换句话说，事件风暴告诉你“有哪些事要发生”，六爻法告诉你“这些事应该在哪个层次发生”，DDD 告诉你“这个层次内部应该怎么组织”，可观测性数据告诉你“现在实际发生得怎么样”。四个工具各管一段，拼起来就是一套从业务到代码、从静态到动态的完整治理循环。

我个人在实际操作中的体会是：这套方法最大的价值，不在于它比现有方法论多知道多少技术细节，而在于它逼着团队在动手之前先把话说清楚。这两个月我自己做评审，第一步永远是让负责人填状态表，填完之后，大部分问题已经不是技术问题了，而是团队对系统的认知不统一。很多所谓的“技术难题”，聊到一半你会发现问题其实出在“没人完整描述过系统现状”。

最后再分享一个小的经验：第一次使用这套方法时，不要贪多，只选一个最核心的服务域做一次状态表评审，把六个爻位填完，把当期动爻找出来，就已经成功了一大半。如果你连初爻到上爻都还没对应清楚，就先别急着重构——先让你们团队花一个小时坐下来，把这张表填完，再说别的。