解剖项目开发思路

今天开始解剖项目已有的架构，我需要学习他们是如何落地开发步骤的。首先第一个问题：关于垂直切分按照功能模块进行，那么如何制定先后顺序。我学到的是开发顺序不再是“先搭骨架再填血肉”，而是按照依赖做拓扑排序，通过横切解耦设计（ActorContext 和 Spring Security）和契约文档，提高后期功能添加补充的便利性。

既然是拓扑结构，那么系统底层原理就是一张依赖图，按照节点代表模块能力，边代表依赖请求关系。但是拓扑排序只是外壳，真正难的是如何找到横切关注点。在这个项目中就是身份权限，不依赖任何其余模块，入度最高，出度为 0，几乎全部都要依赖它。

第二，在拓扑排序中有个前提，图不可有环，否则就是设计错误。如果必须出现双方互相依赖关系，先破坏再排序。比如在管理平台中资产和软件都依赖工单，再让工单反过来引用软件，就形成了一个环。对于解法就是寻找一个共同的下游，把逻辑抽成公共层，让依赖单项。所以刚刚的现象那就是工单作为共同下游，资产和软件都依赖工单，但是工单不反过来引用他们，只需要正常将所有的内容进行创建工单。

第三就是契约层，但是为了防止 AI 通过需求写代码造成的局部最优解，一定要先写接口签名。从需求中提炼契约的时候，要去理解出模块有哪些，之间的关系如何调用，每个调用需要输入什么，每个调用返回什么。

然后就是开发顺序要抽象成分层而不是先后。从数据底座是谁要用，先建立，然后横切能力贯穿全部模块，再去做领域核心，这是真正的业务，然后把各个模块聚合编排，最后做出前端入口。

如果把这套能力迁移到别的项目中，第一步就是先画图，把系统拆成“能力”，发现依赖边，然后找出依赖最多的节点，统计每个节点的入度，最高的通常就是三个类别，数据模型，横切能力，领域模型。第三步就是破坏，把所有的环提公共层，拆单向下游，或者引入事件解耦。第四步就是将上述的内容写成契约，每个模块都要先写接口签名和语义，定死为一个设计文档，实现可以迭代，但是契约要评审后才能改。最后就是按照拓扑结构开发，每层独立验证了，用真实下层加 mock 上层进行验证。

最后一句话总结，开发顺序不是排期表，是依赖图拓扑序。排序之前先做三件事：把横切关注层抽出来当第一层，把环破坏变成依赖单项，把接口契约写死。