前言

每天CRUD的你了解什么是业务逻辑吗？我们常常说后端程序员的工作就写业务逻辑，那到底什么是业务逻辑呢？

1、业务逻辑

wiki百科中定义了业务逻辑，业务逻辑就是领域逻辑，是对现实世界中的业务规则的编码，业务逻辑决定了数据的创建、存储和变更。

In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed

2、业务规则

业务规则描述了一个业务可以干什么、不能干什么、有什么约束。每个业务都是利用一套相对固定的程序来组织系统，并利用这套步骤来完成业务，这套步骤里就包括了完成业务可以做的一些行为，事实上业务规则无论是否用代码实现都是可以工作的，代码只是提高生产力的手段。

3、举个例子

银行转账，比如你是银行业务员，先不通过代码考虑，单纯考虑这个银行业务
首先，你需要了解：
1、发起转账的人是谁
2、转出的金额是多少
3、发起转账的账号
4、接受转账的账号

业务规则

以下业务规则约束了业务员要做的业务
a、发起转账的人必须有这个权限
b、转账过程必须是原子的
c、如果超过10万，必须通知政府
d、金额必须小于账户剩余总额
e、要转账的银行必须与当前银行可以直接互通
f、其他。。。

业务逻辑
业务规则是组织赚钱的核心逻辑，即便没有代码人家一样可以运转，赚钱，代码不过是提高生产力的一种手段。
业务逻辑就是针对业务规则进行的编码操作，以上面的业务规则为例，编码的时候可以采用
A：三层架构
抽象一个TransferServiceImpl，然后里边有一个方法叫transfer(Account a, Account b)，然后再transfer方法中写这些业务逻辑，做各种判断等，Account账户是单纯的数据容器，里面包含各种get、set方法，可以获取账户所有信息。
B：DDD架构
抽象两个Account聚合，和一个领域服务，领域服务TransferService中有一个方法是transfer(Account a, Account b)，真正转账的动作是a.judge、a.reduce，b.judge、b.increase，即真正做业务逻辑是在两个账户里而不是在领域服务里。

充血模型和失血模型
上面的两种架构模式一个产出了失血模型，即Account；另一个产出了充血模型，也是Account；所谓失血和充血就是对象里是否有除了get、set的其他业务逻辑。
A：充血模型
充血模型包含业务逻辑，更加符合高内聚的代码设计目标，同时代码也更加可读，比如account.reduce(10)表示账户减少10元。
B：失血模型
失血模型只包含数据和get、set方法，业务逻辑分散在多个service中，如果要减少10元，那么需要account.set(account.get()-10)，并且这部分代码是在某个service中完成的，代码不可读的同时也不方便维护。后续代码膨胀的时候一个账户方法可能被多个service引用。

4、区分领域逻辑和应用服务逻辑

• 领域逻辑（业务逻辑、业务规则、领域知识）是做关键业务决策的主角，即业务决定都是由领域逻辑完成的
• 协调做关键业务决策的逻辑是应用服务逻辑

举个例子：

银行取钱：

• 先确定该账户是否可以取钱
• 如果可取，计算扣除手续费的余额
• 执行取钱
• 短信通知
  上述业务是一个应用服务逻辑，只有执行取钱的时候是由领域模型作的决定，其他的都是协调做取钱这个业务逻辑的辅助逻辑。