【目的】
原则性指导业务逻辑设计处理；具体项目（模块）具体分析。
原则：
一、逻辑涉及范围仅在完整的应用模块
二、逻辑的处理需要考虑存储上关系的紧密程度
三、业务逻辑处理的层次最好在3层以内，不能无限传递
常规下，一个项目包括多个应用模块，每一个应用模块都需要各自的存储资源，且有自身的一套处理流程
每一个应用模块都有对应的前置条件、后置条件。
那么模块的粒度不要过于小巧，也不要过于庞大
【具体演示】
现在常规项目开发都是采用N层结构（其中包括DB访问层（Sp）和业务逻辑层），DB存储
DB访问层：调用的是SP（存储过程），输出原始数据
业务逻辑层：调用的是DB访问层，输出已处理或前台需要的数据
场景一：
管理员保存公告
分析：角色（管理员），动作（保存），对象（公告）
业务上来说，公告模块属于独立的模块应用，完整的
发布公告的人和公告本身无关
那么：DB访问层下的SP可以完全公开，其公告的处理逻辑（权限）全由业务层处理
场景二：
评论流程，一张评论表，一张对象表（包括一个静态字段：评论数）。
那么，每次保存评论时，更新评论数应该由SP来完成还是业务处理层完成
个人建议：SP完成
原因：减小通讯和DB链接次数
场景三：
网购流程：下单->支付->更新支付状态->更新下单状态
此类逻辑处理采用一致方式处理，也就是说：SP必须限定，业务也要限定，切限定逻辑一致，但允许方式不一样
最后，也许此文描述的不恰当，望不断修正。
开发团队建议人员：
1、系统开发员
2、DB开发员
3、业务开发员
4、前台开发员
5、测试开发员
此文涉及人员是前3类，2和3协商处理逻辑｛协商问题：逻辑重点在DB还是业务，还是分别实现同一逻辑处理｝，实在不好确定的，由1来拍板实现逻辑
希望此文对自己以后开发有帮助和提升！
软件重点在于业务逻辑，切记！