下面举个关于实体之间的栗子：我之前接过的一个项目，其中有一条这样的逻辑“一个经销商下最多3个联系人”;这时我们会疑问，为啥会有这种设定， 这样的规则在后续会产生哪些问题呢：

　　当经销商下联系人超过3个时，系统是不支持的;

　　系统是由简到繁的过程，一开始设定这样的限制，如果后面想在撤销这种设定的话会涉及很多改动;

　　实体之间不够独立且依赖太多，所以这不遵循高内聚低耦合的原则; 其实这就是简单的1：N的关系，只是在某些特定方式下，如导入经销商及其联系人的时候，这时我们可以设定这个联系人最多是3个，但是，在系统的使用中，这种关系反而是一种负担;

　　2.3 遵循“复用性”原则，所有设计力求复用最优化

　　官方解释：

　　可复用性，复用又叫重用，是重复使用的意思。复用的好处可以得到 较高的生产效率以及随之而来的成本降低、较高的软件质量(错误可以更快的被纠正)以及 恰当的使用复用可以改善系统的可维护性。

　　模块之间的复用，即实体的复用，当实体之间是N:N的关系时，一定会存在这样的复用关系;如果不存在，那这个设计可能没有达到复用最优化的标准;

　　如我们常见的组件与商品的关系，是N:N，在商品新建时会以属性的方式增加组件;

　　这样做的好处是：

　　组件不需要重复新建，直接在商品新增时引用加入即可;

　　可对组件进行管理、控制;

　　如果我们换一种设计思维，如新建商品时，一个个编辑填写组件信息，这样做会带来

　　如不同商品的组件信息相同时，要重复录入;

　　组件是以属性的方式附属在商品上，达不到组件可控可管的需求;

　　阶梯性关联关系的设计，即多个实体之间有阶梯性关联关系，建议采用断层式数据结构设计，不建议跨级发生联系，即使需要跨级也要把中间那层关系加上;

　　为了便于理解，以下实例奉上。

　　背景：项目-经销商是N:N的关系，经销商-联系人是1：N的关系;

　　需求1：当项目新增成功后，会根据一定条件匹配经销商，确认此项目可能推送的经销商，或者叫预推送;此时的预推送表结构的设计应该是项目-经销商，而不是项目-联系人或项目-经销商-联系人;这样设计的好处有，

　　我们只固定了前半边的关系，后面的关系可以通过经销商来匹配带出，当经销商人员发生变更时也不会有任何影响;如果采用其他方式，在经销商人员变更时会多出很多复杂的数据操作，以保证此功能不受影响;

　　经销商-联系人是1：N的关系，插入一条项目-经销商关系就要插入多条项目-联系人或项目-经销商-联系人的关系，从数据的冗余角度考虑，也是项目-经销商的关系比较适合;

　　需求2：项目推送，项目预推送匹配成功后，可以对项目进行推送，这是真正的推送，有了这条推送，联系人才能在前端看到对应的项目;而此时的设计应该是如何呢

　　答案是，项目-经销商-联系人;为什么会加入“经销商”呢?前面的背景也说到，项目与联系人其实是没有这种关系的，他们产生关系的载体其实就是“经销商”;这样做的好处是

　　明确该联系人时通过什么载体(即经销商)来获得这从推送关系的，当联系人与载体的关系发生变更时，有个依据来对关联数据进行相关操作;如联系人从载体A变更到B，那此时，联系人当时通过A获得的项目推送关系就应该删除;

　　相反的，如果不加入“经销商”的载体，那联系人可见的项目是只增不减，因为我们没有这个载体的依据去操作数据;

　　注：一切实际需求为标准，仅供参考;

　　三、日常设计要点

　　3.1 保持对需求的严谨态度

　　虽然需求多如牛毛，产品累成狗(微笑)，但我们也要始终保持一颗严谨、谦逊的态度;做软件的都知道，即使是一个很小的需求，他的改动有时也不一定比一个大的需求少;所以，在需求被提出时，我们要保证我们已经了解到该需求的所有细节，以及涉及到的所有改动点;

　　3.2 尽量囊括所有扩展场景

　　好的产品，流程极简且不容易发生异常;为什么说不容易呢，因为即使是神，也有考虑不周的地方，所以在设计时，应尽量囊括所有场景。

　　(1)外部条件导致的异常如断网、服务挂掉等，应给出合适的提示信息;

　　(2)另外还有一种，即在常规流程外的分支流程，这个是特别需要我们注意且控制的。

　　重复提交：提交按钮没有控制可用状态&&页面流程较慢的情况下会出现多次重复提交的现象，一般前端+后台，双重控制，杜绝重读提交;

　　流程异常，无法继续走下去：充分考虑扩展场景，避免出现操作异常，即使异常，也应给出相关提示，指导用户继续走下去。

　　3.3 模块关联性，版本规划