《软件架构基础》系列是对Mark Richards 和 Neal Ford编写的 Fundamentals of Software Architecture 的读书总结, 本文介绍了架构特征的识别。
目录
识别架构特征是创建架构或者分析现有架构的第一步。有三个识别途径:
- 从领域关注点(domain concerns)中提取架构特征
- 从显性需求描述中提取架构特征
- 从隐性领域知识中提取架构特征
从领域关注点中提取架构特征
领域关注点(domain concerns)指的是架构师与领域干系人(domain stakeholder)一起合作而确定的从领域角度来说真正重要的那些问题点。例如,产品上市时间、用户满意度、预算等问题都属于领域关注点。
首先,架构师应倾听领域干系人的观点,并且和他们一起合作确定出他们的领域关注点。然后架构师把领域关注点转换成最终的架构特征。因为领域干系人描述领域关注点采用的语言和架构师描述的架构特征采用的语言是不同的,从领域关注点到架构特征实质是一个翻译(translate)过程。
架构师可以借助翻译表(如下表)把领域关注点翻译成架构特征。
领域关注点 | 架构特征 |
兼并和收购 Mergers and acquisitions | 互操作性,可伸缩性,适应性,可扩展性 Interoperability, scalability, adaptability, extensibility |
产品上市时间 Time to market | 敏捷性,可测试性,可部署性 Agility, testability, deployability |
用户满意度 User satisfaction | 性能,可用性,容错性,可测试性,可部署性,敏捷性,信息安全 Performance, availability, fault tolerance, testability, deployability, agility, security |
竞争优势 Competitive advantage | 敏捷性,可测试性,可部署性,可伸缩性,可用性,容错性 Agility, testability, deployability, scalability, availability, fault tolerance |
时间和预算 Time and budget | 简单性,可行性 Simplicity, feasibility |
从显性需求描述中提取架构特征
需求文档显式地描述了业务需求,在具体的业务需求中也可能蕴含着架构特征。
架构师可以借助架构特征检查表(Checklist)工具来从业务需求从提取架构特征。该检查表中包含了上一章节中列出的常见架构特征。架构师逐个分析每个业务需求,对照检查表,判断该业务需求是否对应了一个或多个的架构特征。
从隐性领域知识中提取架构特征
隐性的架构特征往往不能直接从需求文档中得到,需要架构师有足够的领域知识挖掘隐含在需求背后的架构特征。
例如,大部分的应用都需要考虑可用性,但是在需求文档中可能不会直接显式地说明,此时需要架构师结合实际的领域问题,判断是否需要考虑可用性作为架构特征。
和从显性需求中提取架构特征类似,检查表(Checklist)也是一个可以使用的工具。可以反向地进行思考,遍历查看常见架构特征列表中的每个特征,结合领域知识,逐个判定是否需要在设计时考虑该特征。
总结
在识别架构特征时,可以使用领域关注点翻译表和架构特征检查表从领域关注点、显性需求文档、隐性领域知识中提取架构特征。