过去曾经做过两次类似系统
但是并没有总结出设计过程
这次在过程中写了一些东西
整个的大致过程是
1. 建模/概要设计
-
得到大致的需求描述
-
从需求中找出关键的概念(将会作为主要的模型)
-
确定各个概念之间的关系(将会决定模型的数据结构)
-
确定各个概念之间的动作行为(将会决定需要设计哪些接口)
为了避免过度纠结，无法推进，不用一步到位，只需要有个大概就可以。在后续的过程中如果发现问题，还可以对设计进行修正。
2. 分层设计
参考了过去的一些工作经验,我们常常都会采用分层式设计.
故将程序大致分成了以下若干层
前端部分
- View层(html模板)
- Controller层(控制View的交互逻辑)
- API层(封装了ajax调用)
对于前端的部分具体怎么写，与我们选择的框架(react.js) 结合,目前还没搞清楚.
主要来看看后端.
后端部分 由外向内分别为
- Controller层(暴露API给前端调用)
- Service层(主要业务逻辑都在这一层)
- Dao层(封装了对于数据库的增删改查操作)
调用层次为 Controller->Service->Dao
需要注意的是不要有跨层的操作.
即Controller不要直接调用Dao
另贯穿于各层之间的为Model层
我们又把Model分成了两种
- do 数据对象-是直接与数据库或者持久化对应的
- bo 业务对象-通常是由数据对象经过转换/组合得出的,为方便业务逻辑使用而存在
3. 测试驱动开发
在有了建模和分层的情况下，就可以写出框架代码了。
这时为了能够及时的验证业务逻辑的正确性，我们采用一边编写测试一边编写业务逻辑代码的方法(TDD)。
由于经验不足，可能实施的过程并不会很满意，我们可以逐步改进。
主要的过程为
- 设计测试用例
- 编写测试代码(红)
- 编写业务逻辑代码(绿)
- 重构业务逻辑,使之更合理
3.1 设计测试用例
主要就是定义出整个场景的流程。
可以用类似5W的方法去定义.
有哪些对象参与，经历了哪些步骤，每个步骤的输入是怎样的，最后得出的结果应当是如何。
结合一开始的需求来做
3.2 编写测试代码
可以与设计测试用例的过程同时进行。
3.3 编写业务逻辑代码
略
3.4 重构
审视代码,在测试的保护下进行重构.略
4. 前端设计
4.1 用户界面
由于目前我们没有专门的交互设计。
可以自行根据需求画出各个界面的线框图。这一步可以与后端用例设计结合着做，通常界面与API都有着一定的关联性。
4.2 api
与后端的RestAPI直接对应
下面是一段随意的记载
功能决定如何建模,模型决定如何扩展
不知道原话是谁说的 在温昱著《软件架构设计》的书中看到这句话.
觉得挺有道理，但又不知道有道理在什么地方