2.3 为什么要做架构设计

2.3.1 由模型到实施

无数的著作中都论及了软件架构和建筑的关系。我认为架构就如同一张蓝图，没有图纸很难建造房屋。如图2.3所示，一个令人神往的海边建筑涉及的方面非常多，具体实施过程包括各种测量和计算，没有一个架构设计的过程是不可能建造成功的。

图2.3

如图2.4所示，室内的图纸也有建筑分布、水电图等，以服务于不同的目标。水电图用于指导水电施工，如果搞错了，再返工也是蛮复杂的一件事情。

图2.4

2.3.2 业务规模发展带来的复杂度

如果说设计师给你的效果图相当于UI设计的话，那么建筑工人建造的就是设计的骨架了（比如架构分层、部署）。而合适的架构可以见微知著，适应变化，在快速规模化效应到来时较好地解决客户的问题，如图2.5和图2.6所示的2个例子。

图2.5

图2.6

一艘民用的船只如果想要发展成一艘巨舰，就需要在安全性、载重、动力设备、船只内部设计等各方面做出改进。而对于时下很火热的线下O2O业务，广大群众乐于比较价格，计算各种优惠，厂商也乐此不疲地发展营销创新，从街头的跳楼价到打折，不一而足。

如图2.6所示的例子，起初的优惠方式为：打折、立减。转换为规则的表达就是X*折扣比例及X−Y（折扣金额）。演变到第二阶段，优惠方式增加了累计，即打折和立减同时生效。演变到第三阶段便出现了有条件的累计优惠，即阶梯性优惠，指定品种/数量优惠等情况。从三个阶段的可扩展性层面来设计优惠规则，其实并不简单，因为后期的需求与起初相比已经有了很大的不同。

2.3.3 从沟通视角看软件架构

Simon Brown所著的《程序员必读之软件架构》一书中提到了软件架构的若干好处，其中有不少是从沟通的视角来看的，如下：

●让技术团队跟随一个清晰的愿景和路线图。

●对不同的听众，以不同层次的抽象来交流相应的问题域和解决方案。

对于第二点，笔者感同身受。有时候，当产品经理、应用架构师、开发人员甚至还有业务领域专家一起讨论交流时，大家对一个概念有不同的说法，统一名称、形成共识往往是设计架构方案的第一步。