软件架构是一门学科,开始于 20 世纪 70 年代。面对不断增加的复杂性和开发复杂实时系统的压力,作为主流系统工程和软件开发的基本构造,软件架构应运而生。与任何其他久经考验的学科一样,软件架构在诞生之初也面临许多挑战!
为什么说我们需要软件架构图?软件架构图能帮我们解决什么问题?
我们尝试通过创建架构图(作为技术文档的一部分)来反映应用程序的内部状态,但大多数时候我们都没能做对。由此产生的架构图可能非常全面,也可能非常模糊。有时,架构图根本就是不相关的。
即使创建了相关的架构图,我们也很少更新它们,作为持续开发过程的一部分。实际上,我们只是时不时地更新文档,可能是在某些 sprint 期间(当有时间更新文档时)或在发布特定版本之前。另一方面,大多数开发人员(参加我的软件架构课程的同事或学生)不赞成创建和维护技术文档,他们认为这些任务乏味、耗时,而且价值不如其他任务,他们甚至认为如果源代码写得足够好,文档不是必需的。虽然总会有例外,但我很确定,在架构图方面,对于大多数项目来说几乎都是一样的。
那么,我们用架构图来做什么?
一般而言,架构图和文档应该主要用于团队内部和团队之间的协作、沟通、愿景和指导。它们还应该包含项目的重要设计决策(在某个特定时刻采取)。
架构图应该帮助每个人看到大局,了解周围的环境。在我看来,这应该是创建和维护架构图背后的根本原因。
例如,上下文架构图完全满足了这种需求,并提供了关于系统边界的大量细节,从而可以看到全局。它有助于团队在不同的利益相关者之间达成共识,并简化沟通。我参加了很多会议,当大屏幕上出现这样的上下文架构图时,省去了很多问题,并消除了关于高级系统架构的不确定性。
不过,我们经常会尝试创建综合性的文档来反映系统的内部状态,它们可以是状态图、活动图、类图、实体图、并发图等形式。但这些很快就会过时,除非它们是基于源代码通过一些“神奇”的工具自动生成的。
因此,创建有意义的小型架构图,并将它们加到技术文档中。对于大多数应用程序,可能需要两三种架构图。最常见的是上下文图、组件图、系统图或部署图。
项目实例
在项目中,我主要使用两种类型的架构图
上下文图
应用程序或软件组件图
请将这些图视为简单的示例,主要作为每种图应该提供哪些合理信息的指导。图中的信息应该与相应的抽象级别相关,还必须满足利益相关者的需求。
在实践中,你可能倾向于向图中添加越来越多的细节,但是如果它们对利益相关者没有真正的用处,就会导致额外的噪音,增加维护成本,而且容易过时。这些图中的一些细节,例如协议和数据格式,可能对技术利益相关者来说比较方便,因为它们是必要的实现细节。然而,正如之前所述,并不存在精确的方法来确定图中包含多少数量的细节才算是恰当的,这完全取决于不同的项目。不过,架构师需要知道对利益相关者来说真正有用的是什么,并创建和维护架构图来正确地反映这一点。
除了这些架构图之外的任何额外细节,我可以在源代码中找到,或者通过某些工具自动生成(例如运行时视图、开发视图、系统或基础设施视图等)。
另外,请记住,团队应该是架构图的主要受益者。如果它们没有表现出任何兴趣,那么你应该停止创建它们,因为这可能是在浪费时间。我们不应该只是“为了拥有它们”,或者为了遵循综合性的架构方法,或者纯粹为了证明我们作为架构师的角色而去创建架构图