PM Suite案例中两派概念的同时体现

团队对架构理解不一致是常见现象，空洞的理论说教解决不了这个问题，结合手上的实际工作来理解架构含义才是可行路径——书中用一个具体案例演示了这一点：某程序管理系统PM Suite需要支持”查看甘特图”，架构师老王没有直接讲理论，而是带着开发骨干小张一起分析实际设计。第一步是”和具体技术无关”的架构方案：因为任务的计划与分配信息，和展示方式（表格还是甘特图）本应无关，于是采用MVC思想把业务逻辑和展现逻辑分开成”业务层”和”展现层”两个粗粒度黑盒组件。第二步引入具体技术问题：甘特图绘制包是自研还是用第三方SDK？用户不关心这个、工期又紧，倾向用第三方SDK，但又不想让系统”绑死”在特定SDK上——于是架构师决定采用第三方SDK，但自主定义一个”甘特图绘制接口”把SDK隔离开，这正是[[组成派与决策派两大架构定义流派]]之外的另一层落地：Adapter（适配器）模式的应用，让系统可以复用一个接口不符合自身需求的已存在的类，也让该类未来的不可预见变化只影响适配器本身、不波及适配器的客户类。回顾这两步设计，组成派视角能看到”组件”从图2-11里粗粒度、完全黑盒的”业务层/展现层”，演变成图2-12里PrgMgtModel、GanttChart、GanttChartImpl这些具体类，组件从黑盒变成了灰盒；也能看到”交互”从粗粒度的”展现层读取业务层数据”，落实成”GanttChartImpl从PrgMgtModel读取数据”这样具体的调用关系。决策派视角则能看到”业务层与展现层分离”体现了关于软件系统组织的决策，而引入GanttChart接口隔离第三方SDK这个决策，直接给架构带来了弹性——未来发现更强大的甘特图程序包、或决定自行开发绘制部分时，只需更改GanttChartImpl一处，其余组件都不用动。这个案例说明组成派和决策派并非互相排斥的”选边站”，它们只是审视同一个具体架构设计时所站的角度不同，一个具体设计里两种视角必然同时都能找到对应的体现。