很多典型的软件架构文档模板用来编写辅助文档实际上没有那么糟，但各个部分的名字往往令人困惑。如果你看了我刚才展示的标题清单，可能会好奇，典型的软件架构“视图”在哪里。
如果你以前没见看过这些，就有很多不同的方式来察看一个软件系统。例子有IEEE 14714 、ISO/IEC/IEEE 42010 5 、菲利浦·克鲁西腾（Philippe Kruchten）6 的4+1模型7 等。它们的共同之处是都给一个软件系统提供了不同的“视图”来描述不同的方面。比如，通常有“逻辑视图”、“物理视图”、“开发视图”，等等。
4 http://en.wikipedia.org/wiki/IEEE_1471
5 http://en.wikipedia.org/wiki/ISO/IEC_42010
6 加拿大软件工程师，英属哥伦比亚大学教授，http://en.wikipedia.org/wiki/Philippe_Kruchten 。——译者注
7 http://en.wikipedia.org/wiki/4%2B1_architectural_view_model
我发现很多方法都有个大问题，如果人们不熟悉方法使用的术语，很快就会变得困惑。比如，我听过到有人争论“概念视图”和“逻辑视图”有什么不同。我们还是不要开始关于是否允许技术出现在逻辑视图的问题吧！观点也很重要。如果我是一个软件开发者，“开发视图”是不是就是代码，或是说那叫“实施视图”？但“物理视图”又是什么？我的意思是，代码就是物理输出，对吧？但对基础设施架构师而言，“物理视图”又是另一个意思。但是，假如目标部署环境是虚拟的而非物理的呢？
我的建议是，不管你如何编写文档，只要明白你想传达的是什么，并相应地给各部分命名。解决术语问题的一个选项是确保团队中每个人对各种架构视图是什么都能找到清晰的定义。在这方面，我高度推荐约恩·伍兹（Eoin Woods）和尼克·罗桑斯基（Nick Rozanski）所著的《软件系统架构》8 。另一个方法是就是将各个部分重新命名来消除歧义。
8 http://www.viewpoints-and-perspectives.info