边界是一个很重要的问题。
-------------------------------------
国与国之间，有边界问题，会发生战争；
省与省之间，有边界问题，会出现三不管；
人与人之间，有边界问题，那是捞过界了，会出现诸如扯皮、小三、打架等等问题；
同理在IT公司内部管理是需要定边界的，职务、职责、部门、流程等等，项目管理也是要定边界的，需求也是要定边界的，设计也是要定边界的，我们看到的大部分东西都是要定边界的。
那设计是怎么定边界呢？
教科书给我们的设计砍了一刀，分为概要设计和详细设计。以前实在不知道该如何解释概要这个词，到现在还是不明白，从语义上难道概要是简单的写，详细是大写特写。这个边界尺度持续了很久都没有把握住。
直至在使用了在文章《混在IT-（6）八股文之需求分析》中的需求规格说明书三分定天下方法之后，对设计的边界有了理解。先举个生活的例子，让大家品味一番。
现在青菜很贵，大叔打算改行去要卖菜。
需求：卖菜
卖菜流程：
1、 大叔推出特价菜，今天是花菜，只欢迎MM
2、 MM选中花菜
3、 MM说要多少斤
4、 大叔把菜放到MM菜篮子里面
5、 MM给钱
6、 大叔笑脸
解决方案：
有大傻很看好大叔卖菜钱途，愿提供环境给大叔，提供了以下解决方案
1、 在街边占地盘卖，愿提供扁担一个，菜篮一对，不过有风险，城管太多
2、 在菜市场租个摊位给大叔，但只能上午营业
3、 建一个专卖店给大叔，可以24小时营业
方案审批：
当然要专卖店，大叔喜欢阵地战，不喜欢游击战，不用到处躲猫猫
概要设计：
讨论怎么建设一个专卖店，怎么装修，怎么布局，怎么更专业
详细设计：
为了把买菜这个流程在这个专卖店做的更好，每个卖菜步骤必须要做包装，如大叔必须装西装、打蝴蝶结等等。但卖菜步骤的是不能变的，这个是原则，这是大叔花了很多心血想出来的。
长远规划：
在这个专卖店上，大叔还可以卖苹果、卖手机……
不知道大家看明白了吗？
总结一下：
概要设计是专卖店建设，详细设计是在这个专卖店上如何实现卖菜流程。
在实践中我们把设计报告也分成3块，其形式和边界如下：
1、 详细设计报告，只涉及到需求规格说明书的分册内容，此部分的内容会随着分册的变动而发生变化。业务实现过程要符合概要设计中的约定。
2、 数据库模型，分册中涉及到数据库部分在数据库建模工具中体现，需要的话可以导出成单独文档存在。
3、 概要设计报告，系统如何建设，与具体的业务无关，是为分册所涉及的业务做支撑的，如网路架构图，部署架构图、数据库设计思路、采用的框架，框架使用的约定，非功能性要求实现等等，这份文档在项目版本迭代过程中可以说基本上是不会再改。做的好还可以在其他项目上使用。
