从需求到设计就像做个汉堡

gumreal

汉堡包有顶、底、中间的肉饼，业务系统有顶上的UI、底层的DB、中间的业务逻辑。
从层次上看是有一些相似的

新项目从哪里开始呢？

首先，谈谈需求吧。
看看客户是干什么的，业务从什么环节开始、什么环节结束，中间需要哪些步骤，涉及的人可分为哪些角色，这些角色都负责什么事。

有了这个理解，就去开始画画吧，画出我们理解的UI原型，去跟客户讨论确切的需求，

业务流程	角色A	角色B	角色C	...
流程环节01	UI-01A	UI-01B	--	...
流程环节02	--	--	UI-02C	...
...	...	...	...	...

按照表中的角色、业务流程去讨论每个UI是否是他们想要的，UI中的控件位置、控件的值域、提交后的结果...，当然如果角色之间对UI的理解有不一致的，就要找他们的老大来决定了。

有了这个UI，汉堡上层的顶就确定了。

第二步是DB设计。
看看顶上这层UI都涉及到了哪些数据信息、它们的关系是什么样的，如何存储这些信息和关系，还有UI上不显示但是必须有的辅助系统管理类信息，如日志等的储存，都一并考虑。
据此设计出DB Schema，这一步保证信息的完整，优化的事等到业务逻辑设计时根据有访问量、数据量再来做。
这样，汉堡下层的底也确定了。

第三步，业务逻辑设计，就是中间的肉饼了。
无论是采用何种技术实现系统、如何划分中间的层次，从UI到DB的过程都是操作数据的过程，反之亦然。
按照UI的交互过程，向后台请求、请求时的参数、希望后台的响应数据及格式，定义出UI调用的接口。
然后分析这些这些接口，功能类似的可以合并，必要时辅助以一些状态标记。
将得到的接口按照功能模块组织起来，使其具有一定的层次目录（package）。

推测这些接口实现时对DB的数据访问要求，对DB设计做出优化。建立相应的索引、或者增加冗余字段、必要时增加cache设计等等。

这样，系统设计初步就是这样了，汉堡也完成了  
实现时还需要对此过程进行反复，以应对需求变更、优化设计等需要。