前几天，一个程序员朋友跟我聊天的时候谈到一个问题，他们开发的系统做了快2年，设计了很多个表，很多个接口。因为代码复杂，现在希望能做一个重构整理代码。这个工程自开发以来从来没有对系统的设计做过盘查，所以这次团队的TL带着大家花了两个礼拜，把里边的接口和表结构用图的形式画了出来，一经梳理，发现了里面有不少的错误，重复设计的表，字段，错误的关联设计。
听到他的描述，我深感认同，因为确实大多数团队做后端设计的时候是不画图的。然后就是需求来了一个劲的加内容，在系统不大时候理清需求与模型设计还算容易，可是系统大了，需求多了（变得更复杂了），时间长了（记不住之前的需求了），团队人员交替了，后面就很难保证不出错。
所以如果在项目一开始就能有某一种图的形式描述系统，并且在未来的迭代开发中保持更新，是一种非常好的项目实践。
问题是，要用怎样的图表示？
为此我搜寻了一些网络的图片和现有方案。
可是无论怎么怎么找，我都不大满意，最大的原因是，我希望这个工具能把产品需求表示进去，而不是强调表结构或者表与表之间的联系。
于是我自己设计了一个工具，起名叫 RDD（requirement-driven-design）
这是一个图型工具，用于理清产品的设计思路，重点在于描述数据库表接口设计与需求的关系。
设计这套图的目的在于：
- 让团队成员能通过读图理解每个数据库表间的设计关系
- 保留产品提出的需求记录，以便之后回顾与分析
- 展示数据流向、存储、合并与输出的关系
这套工具图分成四种色块：
- 深蓝色的代表的是产品需求
- 橘黄色代表数据库表
- 绿色代表后端为实现需求给前端生成的接口
- 紫色代表前端操作给后端发送的数据信息
以电影预定APP的作为例子，做出来是这样的。
例如我们要做一个电影预定APP，类似于猫眼或者淘票票，那么订票就是核心功能，这里还有电影数据库，电影新闻等附属功能。
对于核心功能（订票）而言，需求是用户可以选择一个电影院中的某个场次，某个座位号进行订票，而场次又由电影、影院、影厅决定。
所以这里设计了几个数据库表 电影（Movie） 影院（Cinema) 影厅（Room） 场次（Showing），对于影厅，会有一个选座位的需求，所以给座位分布提供了一个接口，供前端展示选择，座位场次与优惠券最终完成了 订票 的需求。
后端的接口数据库模型最终都是跟着【需求】走的，理解这一点再看这个工具会有更多体会。
例如如果这个APP没有优惠券的功能，那么下面的优惠券部分就不再存在，这样 我的优惠券接口 与 优惠券表 就不需要设计。
若产品变化再添入一个 展示电影演员 的功能。 那么做法就是先将一个【深蓝色块（需求）】加入到图中，写上展示电影演员，再加入一个【橘色块（数据库）】，命名成 演员Cast，然后由 电影 + 演员 的数据合并成 一个【绿色块（接口）】演员列表，如下图：
因为RDD不关心表内的数据字段，所以添加关系内容可以说是一下子就能做好，这样设计的目的在于让图保持简洁，避免在画图过程中做过多的数据结构设计耗费时间。
产品之后会不停迭代，图也跟着需求一直变化，这样每个程序员就可以在图中快速的理解 需求/数据库表/接口 之间的关联，这样很大程度能让每位开发人员理解每个需求每个数据库表设计的意义，达到系统设计的最优化。
