从需求到设计就像做个汉堡
http://i1.peperonity.info/c/AEB462/135950/ssc3/gallery/210-food/hamburger.gif_320_320_256_9223372036854775000_0_1_0.gif汉堡包有顶、底、中间的肉饼，业务系统有顶上的UI、底层的DB、中间的业务逻辑。
从层次上看是有一些相似的http://www.agoit.com/images/smiles/icon_biggrin.gif
新项目从哪里开始呢？
首先，谈谈需求吧。
看看客户是干什么的，业务从什么环节开始、什么环节结束，中间需要哪些步骤，涉及的人可分为哪些角色，这些角色都负责什么事。
有了这个理解，就去开始画画吧，画出我们理解的UI原型，去跟客户讨论确切的需求，
业务流程角色A 角色B 角色C...流程环节01UI-01A UI-01B --...流程环节02-- -- UI-02C......... ... ......
按照表中的角色、业务流程去讨论每个UI是否是他们想要的，UI中的控件位置、控件的值域、提交后的结果...，当然如果角色之间对UI的理解有不一致的，就要找他们的老大来决定了。
有了这个UI，汉堡上层的顶就确定了。
第二步是DB设计。
看看顶上这层UI都涉及到了哪些数据信息、它们的关系是什么样的，如何存储这些信息和关系，还有UI上不显示但是必须有的辅助系统管理类信息，如日志等的储存，都一并考虑。
据此设计出DB Schema，这一步保证信息的完整，优化的事等到业务逻辑设计时根据有访问量、数据量再来做。
这样，汉堡下层的底也确定了。
第三步，业务逻辑设计，就是中间的肉饼了。
无论是采用何种技术实现系统、如何划分中间的层次，从UI到DB的过程都是操作数据的过程，反之亦然。
按照UI的交互过程，向后台请求、请求时的参数、希望后台的响应数据及格式，定义出UI调用的接口。
然后分析这些这些接口，功能类似的可以合并，必要时辅助以一些状态标记。
将得到的接口按照功能模块组织起来，使其具有一定的层次目录（package）。
推测这些接口实现时对DB的数据访问要求，对DB设计做出优化。建立相应的索引、或者增加冗余字段、必要时增加cache设计等等。
这样，系统设计初步就是这样了，汉堡也完成了http://www.agoit.com/images/smiles/icon_biggrin.gif
实现时还需要对此过程进行反复，以应对需求变更、优化设计等需要。
页:
[1]