不要滥用架构隐喻

作者：戴维﹒英格（David Ing）

架构师喜欢使用隐喻（metaphor）。对那些通常比较抽象、复杂和变化移动的目标，隐喻提供了很好的具体媒介。无论是与其他队员沟通，还是与最终用户讨论架构全局，找到有形实物作为正要构建的东西的隐喻，都是十分诱人的。

开始这很有效，使用一种共同语言，也能让大家都感觉到正确的方向，不断演化前进。随着时间推移，隐喻不断发展成长起来，栩栩如生。人们对隐喻感觉良好——我们正在不断前进！

常见的情况是，对于架构来说，之前的那些隐喻现在变得很危险了，滥用架构隐喻经常会出现问题让架构师不知所措，比如：

业务领域的客户开始越来越来喜欢系统隐喻，这时系统还在构想中，在这种情况下，所有各方共享的是最乐观的可能解读（happiest possible interpretation），但其中并没有包括任何必要的约束。

举例而言：“我们正在构建一个运输系统，就像在一系列停靠点之间移动的运输船一样。”

你想的是横渡太平洋的集装箱轮船。而我想的，其实只是在游泳中的单桨划艇。

开发团队开始认为隐喻比实际业务问题更重要。由于团队耽溺（fondness）于隐喻，你不得不开始修正那些古怪的决策。

举例而言：“我们说过，它就像一个文件柜，当然要按字母顺序显示给用户。我知道它是个6维的、没有容量限制并且内置时钟的文件柜，但我们现在己经做好图标了，因此它必须就是一个文件柜……。”

所交付的系统包含了许多遗留名称，从早己老旧过时、有待重新鉴定的隐喻，到多次重构和重复挖掘的概念。

例如：“为什么账单工厂对象（Billing Factory Object）要为划艇系统创建一个港口通道（Port channel）？当然它应该为中心总线（Hub Bus）返回一个石榴视图（Pomegranate view）？你说什么，你是新来的？”

请记住，不要耽溺于系统隐喻之中，只将之用于探索性的沟通，不要反让它拖了后腿。