标签 - 软件工程
本文介绍了从技术架构视角来审视软件体系是如何一步步发展演变，以及为什么说软件工程就像是搭积木。
软件工程是一项既复杂又简单的系统性工程。说它复杂，是因为一整套良好运转的体系是由数百万行代码构建而成的；说它简单，是因为本质上软件体系是无数组件化的小模块拼装而成的，每个研发人员或研发团队只需要维护自己负责的组件与代码模块，复杂度会降低很多。
软件的设计应该像搭积木那样，通过自由拼接组装来实现复杂的功能模块，这样既能保证系统的灵活性，又能避免重复开发，降低成本。如果不能将软件分解成像积木那样的小模块，而是焊死的一块铁板，那么系统将彻底丧失灵活性。
软件系统是如何像搭积木那样拼接出复杂系统的呢？
我们以M公司的Passport系统的开发历史为例，来看看“积木”是如何一块块被搭建起来的。
Passport系统是企业管理客户账号的平台，存储了客户在企业中的注册账号等信息。用户通过App或网站的“个人中心”对账号进行密码管理、邮箱管理等操作，“个人中心”可以理解成Passport系统的用户前台部分。
作为一套完整系统，M公司第一个版本的Passport系统在建设中遵循了经典的MVC范式，如下图所示，数据层“Passport数据库底层”存储了客户账号、密码等数据；业务逻辑层“Passport账号管理服务”包含具体的业务逻辑代码，例如绑定手机、解绑手机的处理逻辑；前端交互层“Passport用户前台”是C端的网站或App上的“个人中心”界面。
第一版Passport系统很好地支持了C端业务，但缺少一个很重要的功能，即供内部业务人员管理用户账号的功能。因此，公司决定开发一套“Passport管理前台”，给业务人员使用。
现在问题来了：给业务人员用的Passport管理前台需要单独开发吗？我们发现不论是给个人用户使用的Passport用户前台，还是给业务人员使用的Passport管理前台，绝大多数的功能都是类似的，例如重置密码、修改关联邮箱等，只是前端界面不同。针对这两套高度类似的功能，如果重复开发一套业务逻辑代码，就会浪费人力，也会造成架构的不合理。
合理的做法是对第一版系统业务逻辑层的核心功能进行服务化处理，即针对“注册账号”“禁用账号”“重置密码”“更新数据”等每一个目标很清晰的功能，将它们抽象成接口，以便于给任何系统提供支持。
因此，我们将后端系统进行服务化改造，并且开发Passport管理前台，与