如果我们要将应用程序，划分为业务逻辑，和插件两个部分。就必须仔细的了解业务逻辑是什么。
严格来讲，业务逻辑，就是只与赚钱或者省钱的业务逻辑与过程。
例如，银行要对借贷者收取N%利息，这个逻辑就是银行获取收入方面的一条业务逻辑。注意，这里并没有提到是让计算机来计算这里的N是多少，还是说让一个银行职员手动输入这个N。也就是说无论这些业务逻辑，是在计算机上实现，还是人工执行的。它们在赚钱/省钱上的作用都是一样的。
我们通常称这种逻辑为关键业务逻辑，因为它们是一项业务的关键部分。
关键业务逻辑通常会需要处理一些数据，比如借贷业务逻辑中，我们需要知道借贷的数量，利率，以及还款日程。这些数据称为关键业务数据，因为这些数据无论自动化程序存在与否，都必须要存在。
关键业务逻辑，和关键业务数据是紧密相连的，所以他们很适合放在同一个对象中处理。我们将这种对象成为业务实体。
业务实体
业务实体是程序中的一种对象，它包含了一系列用于操作关键数据的业务逻辑。它们要么直接包含关键业务数据，要么可以访问这些数据。其接口层，是由实现关键业务逻辑，操作关键数据的函数组成。
下图是一个对应借贷业务的实体类Loan的UML。包含了三个关键业务数据，三个关键业务逻辑的接口。
这个类独自代表了整个业务逻辑，并且与数据库，用户界面，第三方框架等内容无关。所以它可以在任何一个系统中提供与其业务逻辑相关的服务，它不用管这个系统如何呈现数据给用户，数据如何存储，或者以何种方式运行。总而言之，业务实体这个概念中，应该只有业务逻辑，没有别的。
业务实体不一定是一个类，因为它不一定非要用面向对象语言的类来实现。业务实体这个概念只要求我们将关键业务逻辑和关键业务数据绑定在一个独立的软件模块内。
用例
用例是一个为了描述特定场景下的业务逻辑的存在，定义了用户所需要提供的输入数据，用户应该得到的输出信息，以及产生输出后所应该采取的处理步骤。
在今天这个时代，我们通常将用例和API接口绑定在一起，一个API接口可以有多个用例。业务实体并不知道，也不需要知道是哪个用例在调用它，这也是依赖反转原则（DIP）的另一个应用情景。
在作者的描述中，似乎用例是写在代码里，作为一个组件存在的，属于低层概念，而业务逻辑作为高层概念，因为用例靠近输入输出端。
但在今天，我们通常使用API平台来写用例，代码只写单元测试。
请求和响应模型
通常情况下，用例接收数据并产生输出数据。但是一个设计良好的架构中，用例对象通常不应该之道数据应该以什么方式展示。如是在Web还是控制台。所以用例中的代码，不应该出现HTML和SQL。
因此用例类的输入与输出应该只是简单的数据结构（API平台刚好只用在乎简单输入）。
如果非要用代码写用例，那么就不要让输入的数据结构，与输出的数据结构，有所依赖关联，虽然它们可能就是有很多相同的数据。因为它们存在的意义不一样，变更原因和速率也不一样，通过引用或其它方式整合在一起，就是违反了共同闭包原则（CCP）和单一职责原则（SRP）。
本章小结
业务逻辑是一个软件系统存在的意义，属于核心功能，是系统用来赚钱或省钱的那一部分代码。
这些业务逻辑应该保持纯净，不要掺杂用户界面和数据库相关的东西。其他低层次的概念应该以插件形式接入到系统中。业务逻辑应该是系统中最独立，复用性最高的代码。
