不同的项目有不同的功能，不同的功能需要不同的实现，实现这些核心功能的代码就叫业务逻辑 比如让你实现一个功能，给你两个数，让你获取它的和，你所写的如何才能获得任意给定的两个数的和，这个程序实现过程即可成为业务逻辑处理。
“一个人了解的业务逻辑越多越细，他就是越好的需求分析师。”
难题：什么是业务逻辑？
业务是指一个实体单元向另一个实体单元提供的服务。
逻辑是指根据已有的信息推出合理的结论的规律。
业务逻辑是指一个实体单元为了向另一个实体单元提供服务，应该具备的规则与流程。
就像你家的规矩–“吃饭前必须洗手”“有客人来要起立”“睡觉前各自说晚安”-就是业务逻辑的生活化实例。
在软件系统架构中，软件一般分为三个层次：表示层、业务逻辑层和数据访问层：
- 表示层：负责界面和交互；
- 业务逻辑层：负责定义业务逻辑（规则、工作流、数据完整性等），接收来自表示层的数据请求，逻辑判断后，向数据访问层提交请求，并传递数据访问结果，业务逻辑层实际上是一个中间件，起着承上启下的重要作用；
- 数据访问层：负责数据读取。
业务逻辑的内容包括四个部分：
- 领域实体：定义了业务中的对象，对象有属性和行为；
- 业务规则：定义了需要完成一个动作，必须满足的条件；
- 数据完整性：某些数据不可少；
- 工作流：定义了领域实体之间的交互关系。
以大毛网购裤子为例
- 领域实体：大毛、资金账户、订单、裤子、发货单
- 业务规则：大毛点击购买就会生成订单，但必须付了钱，才会发货，生成发货单。
- 数据完整性：淘宝网下订单必须登录账号，没有账号就不能成功购买。
- 工作流：搜索裤子-找到合意裤子-下单购买-付账-收货。
业务逻辑：搜索“裤子”-找到合意裤子-下单-必须登录账号-结算-付账-收货。
当当必须登录账号才能下单成功，亚马逊就不需要，今天发现淘宝也不需要登录账号就能购买商品了，所以每个网站的规则的不同，就形成了不同的业务逻辑，业务逻辑不仅仅包括规则，还包括实体、数据完整性、工作流。如图：
业务逻辑图
业务逻辑也需要画图，叫做业务逻辑图，它跟业务流程图有什么区别呢？
业务流（工作流）是业务逻辑的一部分，它定义了对象之间的交互关系，但不涉及到规则的制定，数据的完整性方面。
其实，我们平常画的业务流程图多数是业务逻辑图。
JavaEE三层架构MVC，把视图控制器模型分开来
那么在这里业务逻辑就是M。
但是什么样的算是业务逻辑如：上传一个文件，上传代码算是一个业务逻辑吗？
数据库操作增加时需要判断，和一些其它这算业务逻辑吗？（我觉得算）
但是hibernate又提供了一个离线查询对象（DetachedCriter），提供这个接口的意思我想是在外面处理业务逻辑。
但是三层架构不是独立的吗？互相不干涉吗？在service层出现sql，hql，criter不是又把dao与service连在一起了吗？
DTO（VO），POJO，BO这些是什么，POJO对应数据库，BO对应业务逻辑，DTO对应页面的传输与显示。
业务逻辑就是处理数据的逻辑啦。一般后台代码也分三层 action(controller) service DAO （这里的三层不是MVC）
比如 我得到用户名 但是在存入数据库的时候 用户名字段应该是前台的用户名加上当前日期拼成的字符串
action或者controller层是第一层 一般是用来及接受数据并且做数据的非空啊 格式是否正确的验证
如用户名是否为空 是不是安全字符串之类的
service层一般是用来做一个业务逻辑的实现
这时候 userName = userName + new Date();
DAO层 就是与数据库交互层啦
也就是读写数据库 将逻辑层得到的新的userName插入到数据库
MVC和三层架构并没有可比性三层架构是指将程序分为数据访问、业务处理、界面三个层次，是软甲整体架构MVC是仅仅是界面架构，也就是它其实只是三层架构的界面部分，M是指实体模型或者实体模型的一个代理，而非领域模型，C是指控制器，仅仅是做转向，不应该包含任何业务逻辑，V就是视图了。至于那些个什么什么O，都是实体在不同层的映射。另外值得一提的是，MVC在一些小的程序中也经常被当做软件整体架构，那个时候M往往就是实体模型了，但是这种时候，V就对M产生了直接引用，也就是界面对实体产生依赖，这是很不好的（但小程序问题不大），此时可以尝试使用MVP模式解耦。至于业务，看你怎么定义领域模型了，一般像上传文件这种操作并不会牵扯企业的业务，那就不应该当做一个业务，但如果这个上传是在工作流或者一些特殊处理中，则有可能上升到业务。怎么做，要看具体问题。