转载自：http://blog.csdn.net/fireball1975/article/details/18767793
摘要：
前文提到我们应该需求驱动设计，那就直接来一个更干脆的做法，我们将需求表示为一个一个的用户故事，软件设计分别针对用户故事来做就行了，只要将用户故事逐个实现了，系统也就完成了。果然能这样做吗？
大纲：
1.什么是优秀的设计？ 2.优秀的设计能节省项目工作量 3.优秀设计从分析需求开始 4.软件系统不是木桶型的 5.软件设计的“大道理” 6.规划系统骨架——架构设计 7.打造系统的底蕴——数据库设计 8.细节决定成败——详细设计 9.用户感觉好才是真的好——用户体验设计 10.持续提升设计水平
本文章是系列文章之一，如果你还没有看过之前的文章，建议先看完前面的文章再看本篇，这样效果更好。
4.1 某种“需求直接驱动设计”的工作方法
案例分析：某敏捷实践项目小组的设计方式
某项目小组正在如火如荼地实践敏捷，任务看板上已经粘贴了很多“用户故事”，项目小组经常在看板前讨论问题：
1）讨论每一个用户故事的实现方法，并进行估算； 2）项目小组成员领取用户故事，负责实现该用户故事； 3）每天检讨进度情况和遇到的问题。
该工作模式给项目小组带来了新鲜的动力，调动了大家的工作热情，取得一定的工作成绩，但也带来了一些思考：
1）只要我们将每一个用户故事的设计想好并实现，每个用户故事都能通过测试，软件就能完成？ 2）用户故事之间没有关系吗？软件设计不需要统筹考虑全部的用户故事吗？
4.2 软件是木桶型的吗？
请看图：
图3.1 软件是这样工作的吗？
一般我们的系统会采用分层架构，以三层架构为例子：
1）最外面的是表现层，主要就是程序的界面了； 2）界面后面就是我们写的程序； 3）程序后面就是数据库。
按照上述的“需求直接驱动设计”的工作模式，只要有新的需求，其实就是有新的用户故事，那么在这个用户故事驱动下，直接设计对应的界面、程序和数据库表就行了。这样的框架下工作，我们可以无惧需求变更。软件就是一个大木桶，需要实现更多需求，那就增加更多的木条就可以了；如果要修改需求，那就修改某条木条就可以了！
我发现很多系统是按照这样的思路来设计的，举一个某电信网站的例子。
我到该网站交费，发现有免费宽带提速的服务，需要输入电话号码来确认该电话线路是否具备提速的条件。我觉得很郁闷，明明我已经登录系统了，系统应该知道我的电话号码，为啥还要我填一次？好吧，为了免费提速，我就输入一次电话号码吧，提交后系统告诉我一个订单号，告诉我大概什么时候会搞定之类的信息。过了几天再次上这个网站，免费提速宽带的窗口又弹出来，我很烦关掉它：我已经提交订单了，还干嘛一直提示我！但它又继续弹出来，我烦了，那再提交一次订单吧，居然可以提交成功！被这样的系统折腾几次其实也不算什么，只要能免费提速也就值了，但最终的结果是电信一直没有帮我提速，我也懒得去投诉了，按照我以往投诉的历史经验，那是折腾自己的事情！
很多商家在不同时期有很多的促销等市场活动，需要软件系统来支持。我们按照木桶原理来做系统的话，看上去似乎事情变简单，但功能与功能之间其实存在很多交叉点，不考虑这些情况，会导致很多问题：
1）首先是用户体验超级不爽。有些系统甚至没有做到用户信息和权限信息共享，就好像上述这个电信例子。 2）没有能发现功能与功能之间的“重用”部分，没有从架构上和数据库底层上认真规划，其实会带来更大的总体工作量。 3）会留下一些系统漏洞甚至是安全漏洞，万一出问题后果很严重。
4.3 软件的内部架构是怎样的？
请看图：
图3.2 软件常见的工作模式
此图说明了以下问题：
1）需求并不是由一个个孤立的“用户故事"组成的，业务概念、业务流程其实是贯穿多个用户故事的，软件设计应该多从业务概念、业务流程的角度来思考； 2）表面上看上去一个用户故事对应一组界面，其实界面之间是很可能有重用和共享部分的； 3）业务逻辑层中的一些类很难将其分拆开来与用户故事、界面组一一对应，存在交叉、共享和重用的可能； 4）数据操作层的代码，有可能是用工具自动生成的、通用的；
5）数据层中的某张表，通常会支撑多个用户故事而不是一个用户故事。
下面我在列举一下无法单独考虑的设计点，以下列出来的可能都需要从软件架构上做一个整体的考虑：
1）权限控制； 2）性能要求； 3）日志记录； 4）工作流； 5）全文搜索； 6）多数据库支持； 7）搜索引擎优化；
……
实际上很少需求是可以通过单独添加一些类，加一些数据表就搞定的，需要通盘的考虑。如果我们硬生生地将系统看成是木桶型的，去添加系统的木条，会让软件很丑很难用，存在诸多漏洞，而且工作量会更大。
4.4 小结
有时候由于目前能力有限，无法全面考虑需求，只能暂时按照木桶型的方式来设计系统，这样也不是不可以的，但要注意的是至少要做到：
1）用户信息和权限信息是共享的； 2）要杜绝安全漏洞。
木桶型的设计方法其实会让系统很难用、弹性很差、工作量更大，而且部分需求我们无法通过添加木条的方式搞定，我们需要尽快升级我们的设计水平，下一节开始为你介绍比较实用的软件设计方法。
