Question

有一个普遍的误解：软件架构图需要被困在云里，展现逻辑上高层次的概念和表达，而不是物理的抽象。但它不应该是这样的，把它们带回到现实往往让图变得更容易解释和理解，也让图更好画。

为了说明为什么思考实现有助于绘图，这里有一些我在培训班上经常遇到的场景。

共享组件

想象你利用一个Web服务器、一个应用程序服务器和一个数据库设计来设计一个三层的软件系统。在思考驻留在这些容器中的高层次组件时，听到这样的对话并不罕见。

参与者：“既然Web服务器和应用程序服务器都在使用日志组件，我们应该把它画在这两者之外吗？”

我：“你会那样编写代码吗？日志组件会在Web服务器和应用程序服务器之外运行吗？比如说，它真的是一个单独的进程吗？”

参与者：“好吧……不是，它很可能是我们会同时部署到两个服务器上的[JAR文件|DLL|其他]中的一个共享组件。”

我：“好，那么让我们也这样画图。在每个服务器中都包含日志组件，用一个注释、定型或符号把它标为共享组件。”

如果你要实现部署到多个不同服务器的共享日志组件之类的东西，确保你的图反映出这一点，而不是包含一些可能被误认为是单独的中心化日志服务器的东西来误导人们。如果有疑问，问问自己你会如何编写代码。

分层策略

想象你在设计一个内部可分为用户界面层设计、服务层和数据访问层的Web应用程序。

参与者：“我们应该展示所有用户界面与数据库的沟通都要通过服务层吗？”

我：“这是你打算实现的方式吗？或者用户界面会直接访问数据库吗？”

参与者：“我们在考虑可能要采用CQRS1模式，这样用户界面可以绕过服务层，直接使用数据访问层。”

我：“在这种情况下，像你刚才解释的那样画图，从用户界面的服务和数据访问层都画出线。给线标注意图和理由。”

1http://martinfowler.com/bliki/CQRS.html

再说一次，要回答这类问题，最简单的方式就是搞明白你要如何编写代码。

图应该反映现实

如果你以画图来回顾性地交流软件系统，那么问题就变成了“我们会这样编写代码吗”。然而，原则是相同的。图应该表达反映现实的抽象，而不是对不存在的进行概念化表现。你应该能看到图的元素反映在代码库中，反之亦然。如果你能明白自己要如何编写代码，就能知道如何可视化。