阿里妹导读： 什么是设计？什么是架构？从零开始建立一个新的系统，新写的每行代码都可能成为明天的历史包袱？如何能有效的在遗留代码上工作？今天，阿里资深技术专家辉子为我们带来 NBF 框架下软件工程架构设计通用方法论，值得细细品读。

Note：本文讨论的是基于服务化前提下的通用软件工程架构方法论，并未涉及到微观设计或架构的具体细节。

前言

即使代码多年的人都会对这两个问题有点蒙圈：什么是设计？什么是架构？

从单词上看：设计是 Software Design，架构是 Software Architecture；分别对应的作者是：Designer 和 Architect：

• Architect 都是 Designer，但 Designer 未必是 Architect。正如所有的架构设计都是设计，但设计未必是架构设计；
• Design 关注微观代码 (inside component)，Architecture 关注宏观软件结构 (between components)；
• Architect 应该都是从 Designer 成长起来的。毕业了用 code 编写软件；成长了用 ppt 设计软件；
• 只会用 ppt 设计，但代码写得不好的 Architect 都是假的 Architect；
• Architecture 里听到比较多的词语：Serverless、FAAS、Microservice、multi-layer、Event driven、OSGI、NBF……
• Design 里听到比较多的词语：SOLID、DDD、正交设计、Design Pattern；
• 搞不清 SOLID，也不可能把软件的层次分好，也无法理解什么是 OSGI 的价值；
• 好的 Designer 是通往好的 Architect 的必经之路。

服务化架构的基本原则

New System

从零开始建立一个新的系统，有几个特征：

• 历史包袱小
• 上下文简单
• 设计的约束小
• 新写的每行代码都可能成为明天的历史包袱

由于调用方还没有，新系统可以比较完美的执行我们预想的架构设计，但是切记，最后那行才是最重要的那行：不要让今天的代码成为明天的历史包袱，新的每行代码都在书写历史。

上图的 1，2，3，4 代表新建系统的顺序：

1. 由“相”抽象出“心”：先思考，那么多的业务场景下“相”，共同的特征“心”是什么。并反向用更多的相去验证心。
2. 将“心”具象成领域模型：关注领域模型 (Domain Model)，解耦数据模型 (Persistence Model)：将 TUNNEL SPI 化。
3. 将领域模型中的依赖 SPI 化：解耦对外部系统的依赖，反转依赖控制权。
4. Mock 所有 spi 实现，确保“心”领域模型包裹的单元测试完全通过
5. 实现 TUNNEL BUNDLE：设计数据模型（Persistence Model），关注“存”，“取”不关注领域模型。
6. 实现依赖 SPI 适配 BUNDLE：连接真实依赖服务。
7. 包装 domain service：模型相关，业务无关。
8. 根据业务需求组合 / 编排 domain service 成为 scenario bundle 或者业务 SOP。

Working on legacy

对于一个软件工程师来讲，写代码最痛苦的事情莫过于 coding on legacy，但同时又给了我们各种说辞：

• 这些代码太烂了，改起来太费劲【需要更多人】
• 这事做不到，因为以前系统架构问题导致的【责任不在我】
• 经过我的修改，现在已经好很多了，工单数量大批下降【我功劳显著】
• 知不知道：接手你代码的人其实也在重复说上述 3 件事情

如何能有效的在遗留代码上工作，业内有本非常不错的书，叫 ”Working Effectively with Legacy Code”, 值得精读：

所以我这里的标题可能不准确，我要讨论的更多是 ” 遗留代码的重构 ”，什么时候我们开始讨论需要把现有系统重构：

• 代码确实腐化到无法正常维护，或者新加一个需求代价很大；
• 目前代码的技术架构满足不了下一步业务的发展；
• 很多特性已经下线作废，却跟有用的代码藕断丝连；
• 业务逻辑随着发展分散到不同的应用里，界限不清；
• 专家级的未雨绸缪，着眼未来的规划和新技术的应用；
• 换老大了，需要立新的 flag。

架构的基本原则依然是上面那幅图。但上下文的不同，我们的发力点和优先级有明显的区别。阿里整个体系里的依赖关系错综复杂，要对阿里环境下的系统做重构是件绝对谨小慎微的事情。为了完成在这么复杂体系下的架构及代码重构，我们必须有条不紊的分离关注点以及一如既往的坚持软件卓越。

聚焦与收敛上游调用

解耦下游依赖

以服务为单位切换

老系统下线

经过一步一步的分解，legacy 系统已经完全被重构，并且具备随时切换的准备。这里我给几个建议：

1. 先把老实现作为 API 的默认实现，新的实现作为老的实现的降级实现，并使用策略分流一部分流量（具体比例跟团队信心相关）；
2. 对于有业务需求变更的部分应尽快实现在新的实现里，并将新实现作为 API 的默认实现，老实现作为新实现的降级实现，策略应该是即时降级，也就是新实现出现问题立刻降级到老实现；
3. 运行一段时间没有问题后，讲所有默认实现切换为新实现，并将老实现作为新实现的降级实现；
4. 其实这时就算所有切换完毕：老实现可以永远作为新实现的降级实现，也就是只要我升级一次服务，上一次成功版本就可以作为这次的降级实现，这样，线上问题回滚就是秒级的。

总结

本文基于借助 NBF 提供的远程多态，服务编排等能力下基础资料，商品，组网等系统新建，重构的经验及方法论总结。仅供遇到架构重构，解耦等问题困扰的技术团队参考。

Note：本文所有图形出自玉简

本文作者：辉子

阅读原文

本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。