- 程序员必读之软件架构
- (英)Simon Brown
- 1193字
- 2020-08-29 01:16:55
第5章 架构对上设计
如果架构是关于结构和愿景的,那设计又是什么?如果你在创建一个解决问题的方案,这不就是设计吗?如果确实如此,那设计和架构有什么区别?
找出区别
对于架构和设计的区别,格雷迪·布奇(Grady Booch)有一个常被引用的定义,可以很好地回答这个问题。在On Design一文中,他说道:
作为名词,设计是指一个系统内命名的(尽管有时无法命名)结构或行为,解决或有助于解决该系统的一个或多个问题。因而设计代表了潜在的决策空间中的一个点。
思考任何一个需要解决的问题,可能都有101种方法。以你目前的软件项目为例,要实现同一目标,可能有多种不同的技术、部署平台和设计方法可选。即使是设计软件系统,你的团队也只是从潜在决策空间里的很多个点中选择一个。
格雷迪还说:
所有架构都是设计,但并非所有设计都是架构。
这很有道理,因为创建一个解决方案本质上就是一次设计练习。然而,出于某些原因,有一个区别使得并非所有设计都是“架构”,对此他声明:
架构反映了使一个系统成型的重要设计决策,而重要性则通过改变的成本来衡量。
从本质上讲,格雷迪认为重要决策即“架构”,其他的都是“设计”。在现实世界中,架构和设计的区别并不明显,但该定义确实为我们提供了一个基准,去思考在我们的软件系统中哪些可能是重要的(或者说“架构的”)。比如说,这可能包括:
❑ 系统的形态(例如,客户端-服务器、基于Web、原生移动客户端、分布式、异步,等等);
❑ 软件系统的结构(例如,组件、层、交互,等等);
❑ 技术选择(即编程语言、部署平台,等等);
❑ 框架选择(例如,Web MVC框架、持久性/ORM框架,等等);
❑ 设计方法/模式选择(例如,针对性能、可伸缩性、可用性等的方法)。
架构决策不可能轻易反悔,那会大费周章。或者说直白点,架构决策很难在一个下午就完成重构。
理解意义
后退一步想想哪些对你的软件系统很重要,这往往是值得的。例如,很多团队使用关系型数据库,这个选择可能被认为很重要。为了减少在数据库技术变化时必要的返工量,很多团队会使用Hibernate或Entity Framework这样的ORM框架。引入额外的ORM层使得数据库操作能与代码的其他部分解耦,而且理论上,不用花费很多精力就能独立地切换数据库。
引入额外层的决策是将某个部分从软件系统中解耦的经典技术,促进了低耦合、高内聚和更好的关注点分离。此外,有了ORM以后,可能一个下午就完成了数据库的切换。从这一点来说,从架构上它不会再被看作是重要的。
然而,当数据库的选择可能不再被当作重要决策时,通过引入额外层实现解耦就应该是重要决策。如果你想知道为什么,试想把你当前所用的ORM或Web MVC框架完全替换成另一个,要花多长时间。当然,你可以在所选的ORM上再添加其他层,以隔离业务逻辑,并提供轻松替换ORM的敏捷性。但是,你又做出了另一个重要决策:引入了额外的分层、复杂性和成本。
尽管“重要决策”没法彻底消失,但能通过架构分层等多种策略来改变。软件系统架构流程的一部分就是搞清楚哪些是重要的及为什么。