问软件架构文档应该展示所使用的技术吗？

EN

我想说的是，这取决于该文件所描述的程度：

• 企业架构 -不，这里可能不应该使用特定的技术，因为本文档应该更多地关注业务流程，以及支持它们的高级组件。
• 解决方案架构 -是的，因为文档描述了一个特定的系统。

如果您没有列出技术，那么您只是列出概念。

概念--没有具体的应用程序和特定的技术--并不是很有趣。

任何人都可以列出一些概念，并声称它们都是以某种神奇的方式一起工作的。

架构在变化中应该是稳定的。

我看不出重点是什么。如果你只想列出概念，它们就永远不会改变。但是，它并没有告诉任何人该买什么，签署什么合同，或者做什么编程。

某些模块可以更改所使用的技术。

如果是的话，您将在哪里记录技术选择？这就是架构文档的作用所在。

它告诉每个人该使用什么。

架构应该提供所使用的技术，但只用于公共API和任何共享资源。

如果我试图弄清楚库存系统将如何与工作订单系统对话，那么我需要知道我的选择是什么。

我并不关心这个系统是用C#或Java开发的，除非它影响到许可或雇用；我确实关心它是使用SOAP、REST还是使用某种EDI。我也关心哪个版本和哪些协议在使用。这些需要放在架构文档中，否则它不会告诉我实际的体系结构。

我还关心数据库--这是一个共享的资源。如果我倾向于将ETL作为解决方案，那么无论源是Oracle还是Server，都会产生很大的不同。

哦，我需要知道关于依赖的事。例如，如果您决定在ESB中使用NServiceBus，我需要知道这一点，因为它需要广泛部署MSMQ，作为一名架构师，我应该能够说出它的可靠性和/或可伸缩性。同样，如果您决定使用WCF进行互证书身份验证，那么我们最好准备部署PKI。

另一方面，我真的不在乎您是否选择了Spring或城堡作为依赖注入，或者您是否在.NET应用程序中使用Linq或Entity。请不要让你的读者对log4net和NLog的优点感到难以忍受的描述。

没有简单的“是”或“不是”的回答--这就像问你在与客户会面时应该涉及多少技术细节一样。答案是“只需要多少”。您是架构师；您应该对体系结构有足够的了解，以便能够确定某些实现细节是否对整个系统或企业有更广泛的影响。