不要滥用架构隐喻
来源:互联网 发布:去日本必买的东西知乎 编辑:程序博客网 时间:2024/06/09 22:42
作者:戴维﹒英格(David Ing)
架构师喜欢使用隐喻(metaphor)。对那些通常比较抽象、复杂和变化移动的目标,隐喻提供了很好的具体媒介。无论是与其他队员沟通,还是与最终用户讨论架构全局,找到有形实物作为正要构建的东西的隐喻,都是十分诱人的。
开始这很有效,使用一种共同语言,也能让大家都感觉到正确的方向,不断演化前进。随着时间推移,隐喻不断发展成长起来,栩栩如生。人们对隐喻感觉良好——我们正在不断前进!
常见的情况是,对于架构来说,之前的那些隐喻现在变得很危险了,滥用架构隐喻经常会出现问题让架构师不知所措,比如:
- 业务领域的客户开始越来越来喜欢系统隐喻,这时系统还在构想中,在这种情况下,所有各方共享的是最乐观的可能解读(happiest possible interpretation),但其中并没有包括任何必要的约束。
举例而言:“我们正在构建一个运输系统,就像在一系列停靠点之间移动的运输船一样。”
你想的是横渡太平洋的集装箱轮船。而我想的,其实只是在游泳中的单桨划艇。
- 开发团队开始认为隐喻比实际业务问题更重要。由于团队耽溺(fondness)于隐喻,你不得不开始修正那些古怪的决策。
举例而言:“我们说过,它就像一个文件柜,当然要按字母顺序显示给用户。我知道它是个6维的、没有容量限制并且内置时钟的文件柜,但我们现在己经做好图标了,因此它必须就是一个文件柜……。”
- 所交付的系统包含了许多遗留名称,从早己老旧过时、有待重新鉴定的隐喻,到多次重构和重复挖掘的概念。
例如:“为什么账单工厂对象(Billing Factory Object)要为划艇系统创建一个港口通道(Port channel)?当然它应该为中心总线(Hub Bus)返回一个石榴视图(Pomegranate view)?你说什么,你是新来的?”
请记住,不要耽溺于系统隐喻之中,只将之用于探索性的沟通,不要反让它拖了后腿。
0 0
- 不要滥用架构隐喻
- 55 不要滥用架构隐喻
- 不要滥用网络资源
- 不要滥用IT规划
- 请不要滥用异常
- 不要滥用继承
- 不要滥用Mock
- 请不要滥用SharedPreference
- 请不要滥用SharedPreference
- 不要滥用SharedPreference
- 请不要滥用SharedPreference
- 不要滥用SharedPreference
- 不要滥用递归
- 请不要滥用SharedPreference
- 不要滥用单例模式
- 不要滥用coalesce()函数
- 性能提升----不要滥用HttpSession
- Android请不要滥用SharedPreference
- ionic结合HTML5实现打电话功能
- Maven中Spring-Data-Redis存储对象(redisTemplate)
- 【HDU1255】【线段树】【扫描线】【面积】
- tomcat插件安装及项目部署
- 向后兼容
- 不要滥用架构隐喻
- Missing Number
- redis获取自增长序号
- java并发:Semaphore 的使用
- java.lang.ClassNotFoundException: org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver
- leetcode Binary Tree Right Side View
- JSON对象遍历
- php导出excel(多种方法)
- 【C Primer Plus】【课后习题】第二章C语言概述