第5章 架构对上设计

如果架构是关于结构和愿景的,那设计又是什么?如果你在创建一个解决问题的方案,这不就是设计吗?如果确实如此,那设计和架构有什么区别?

找出区别

对于架构和设计的区别,格雷迪·布奇(Grady Booch)有一个常被引用的定义,可以很好地回答这个问题。在On Design原文给出的链接http://www.handbookofsoftwarearchitecture.com/index.jsp?page=Blog&part=2006已失效,可访问https://www.ibm.com/developerworks/community/blogs/gradybooch/entry/on_design?lang=en阅读文章。——译者注一文中,他说道:

作为名词,设计是指一个系统内命名的(尽管有时无法命名)结构或行为,解决或有助于解决该系统的一个或多个问题。因而设计代表了潜在的决策空间中的一个点。

思考任何一个需要解决的问题,可能都有101种方法。以你目前的软件项目为例,要实现同一目标,可能有多种不同的技术、部署平台和设计方法可选。即使是设计软件系统,你的团队也只是从潜在决策空间里的很多个点中选择一个。

格雷迪还说:

所有架构都是设计,但并非所有设计都是架构。

这很有道理,因为创建一个解决方案本质上就是一次设计练习。然而,出于某些原因,有一个区别使得并非所有设计都是“架构”,对此他声明:

架构反映了使一个系统成型的重要设计决策,而重要性则通过改变的成本来衡量。

从本质上讲,格雷迪认为重要决策即“架构”,其他的都是“设计”。在现实世界中,架构和设计的区别并不明显,但该定义确实为我们提供了一个基准,去思考在我们的软件系统中哪些可能是重要的(或者说“架构的”)。比如说,这可能包括:

❑ 系统的形态(例如,客户端-服务器、基于Web、原生移动客户端、分布式、异步,等等);

❑ 软件系统的结构(例如,组件、层、交互,等等);

❑ 技术选择(即编程语言、部署平台,等等);

❑ 框架选择(例如,Web MVCModel-View-Controller,模型-视图-控制器。——译者注框架、持久性/ORMObject-Relational Mapping,对象关系映射。——译者注框架,等等);

❑ 设计方法/模式选择(例如,针对性能、可伸缩性、可用性等的方法)。


架构决策不可能轻易反悔,那会大费周章。或者说直白点,架构决策很难在一个下午就完成重构。

理解意义

后退一步想想哪些对你的软件系统很重要,这往往是值得的。例如,很多团队使用关系型数据库,这个选择可能被认为很重要。为了减少在数据库技术变化时必要的返工量,很多团队会使用Hibernate或Entity Framework这样的ORM框架。引入额外的ORM层使得数据库操作能与代码的其他部分解耦,而且理论上,不用花费很多精力就能独立地切换数据库。

引入额外层的决策是将某个部分从软件系统中解耦的经典技术,促进了低耦合、高内聚和更好的关注点分离。此外,有了ORM以后,可能一个下午就完成了数据库的切换。从这一点来说,从架构上它不会再被看作是重要的。

然而,当数据库的选择可能不再被当作重要决策时,通过引入额外层实现解耦就应该是重要决策。如果你想知道为什么,试想把你当前所用的ORM或Web MVC框架完全替换成另一个,要花多长时间。当然,你可以在所选的ORM上再添加其他层,以隔离业务逻辑,并提供轻松替换ORM的敏捷性。但是,你又做出了另一个重要决策:引入了额外的分层、复杂性和成本。

尽管“重要决策”没法彻底消失,但能通过架构分层等多种策略来改变。软件系统架构流程的一部分就是搞清楚哪些是重要的及为什么。