问题

1. “你的业务逻辑层为什么要按照数据库的表来建立。一旦数据库的表更改了岂不是业务逻辑层也要更改么。”当大师傅问我这个问题的时候，我才反应过来我的业务逻辑层理解的有问题，当时我是把业务逻辑都放到了U层，导致U层很累赘。

2.当沾沾自喜以为给U层解负担的时候，惊奇的发现，B层还是被架空了。（这个问题是出于B层依然是按照数据库表来建立的。）

所以，我才重新开始反思 ，业务逻辑层的到底是应该怎么建立，为什么第一次发现这个问题了，还出现业务逻辑层架空的问题。

原因分析

什么是业务逻辑层？

• 业务是指一个实体单元向另一个实体单元提供的服务。
• 逻辑是指根据已有的信息推出合理的结论的规律。

在网上搜索了很多的资料，找了一个解释的蛮有意思的。业务逻辑是指一个实体单元为了向另一个实体单元提供服务，应该具备的规则与流程。就像你家的规矩–“吃饭前必须洗手”“有客人来要起立”“睡觉前各自说晚安”-就是业务逻辑的生活化实例。

业务逻辑的内容包括四个部分：

• 领域实体：定义了业务中的对象，对象有属性和行为；

• 业务规则：定义了需要完成一个动作，必须满足的条件；

• 数据完整性：某些数据不可少；

• 工作流：定义了领域实体之间的交互关系。

下面是假设引用的“以大毛网购裤子”为例的一个例子：

• 领域实体：大毛、资金账户、订单、裤子、发货单

• 业务规则：大毛点击购买就会生成订单，但必须付了钱，才会发货，生成发货单。

• 数据完整性：淘宝网下订单必须登录账号，没有账号就不能成功购买。

• 工作流：搜索裤子-找到合意裤子-下单购买-付账-收货。

所以，在大毛网购裤子这一业务逻辑：搜索“裤子”-找到合意裤子-下单-必须登录账号-结算-付账-收货。

业务逻辑层里到底应该是什么？

笔者在问了很多大神的博客或者论坛里找到了一个比较好的说法：

根据上图的解释，我们首先要明确这些业务逻辑的多种关联动作是在B层内部进行的。那么问题就来了，到底怎么内部进行，进行的这些动作到底是什么，方法么，还是类么还是什么其他的？简单的说通过什么方式才能让这多种关联在形成一个完整的流程。这个问题我们后面再说。其次，“即使是不会变成的人也可以设计业务逻辑”。在机房合作期间，由于之前的重构（未完待续）