角色与权限的设计

过去曾经做过两次类似系统
但是并没有总结出设计过程

这次在过程中写了一些东西

整个的大致过程是

1. 建模/概要设计

1. 得到大致的需求描述

2. 从需求中找出关键的概念(将会作为主要的模型)

3. 确定各个概念之间的关系(将会决定模型的数据结构)

4. 确定各个概念之间的动作行为(将会决定需要设计哪些接口)

为了避免过度纠结，无法推进，不用一步到位，只需要有个大概就可以。在后续的过程中如果发现问题，还可以对设计进行修正。

2. 分层设计

参考了过去的一些工作经验,我们常常都会采用分层式设计.
故将程序大致分成了以下若干层

前端部分

• View层(html模板)
• Controller层(控制View的交互逻辑)
• API层(封装了ajax调用)

对于前端的部分具体怎么写，与我们选择的框架(react.js) 结合,目前还没搞清楚.
主要来看看后端.

后端部分 由外向内分别为

• Controller层(暴露API给前端调用)
• Service层(主要业务逻辑都在这一层)
• Dao层(封装了对于数据库的增删改查操作)

调用层次为 Controller->Service->Dao

需要注意的是不要有跨层的操作.
即Controller不要直接调用Dao

另贯穿于各层之间的为Model层
我们又把Model分成了两种

1. do 数据对象-是直接与数据库或者持久化对应的
2. bo 业务对象-通常是由数据对象经过转换/组合得出的,为方便业务逻辑使用而存在

3. 测试驱动开发

在有了建模和分层的情况下，就可以写出框架代码了。
这时为了能够及时的验证业务逻辑的正确性，我们采用一边编写测试一边编写业务逻辑代码的方法(TDD)。
由于经验不足，可能实施的过程并不会很满意，我们可以逐步改进。

主要的过程为

1. 设计测试用例
2. 编写测试代码(红)
3. 编写业务逻辑代码(绿)
4. 重构业务逻辑,使之更合理

3.1 设计测试用例

主要就是定义出整个场景的流程。
可以用类似5W的方法去定义.

有哪些对象参与，经历了哪些步骤，每个步骤的输入是怎样的，最后得出的结果应当是如何。

结合一开始的需求来做

3.2 编写测试代码

可以与设计测试用例的过程同时进行。

3.3 编写业务逻辑代码

略

3.4 重构

审视代码,在测试的保护下进行重构.略

4. 前端设计

4.1 用户界面

由于目前我们没有专门的交互设计。
可以自行根据需求画出各个界面的线框图。这一步可以与后端用例设计结合着做，通常界面与API都有着一定的关联性。

4.2 api

与后端的RestAPI直接对应

下面是一段随意的记载

功能决定如何建模,模型决定如何扩展
不知道原话是谁说的 在温昱著《软件架构设计》的书中看到这句话.
觉得挺有道理，但又不知道有道理在什么地方