《架构整洁之道》之业务逻辑

如果我们要将自己的应用程序划分为业务逻辑和插件两部分,就必须更仔细地了解业务逻辑究竟是什么,它到底有几种类型。

严格地讲,业务逻辑就是程序中那些真正用于赚钱或省钱的业务逻辑与过程。更严格地讲,无论这些业务逻辑是在计算机上实现的,还是人工执行的,它们在省钱/赚钱上的作用都是一样的。

关键业务逻辑和关键业务数据是紧密相关的,所以它们很适合被放在同一个对象中处理。我们将这种对象称为”业务实体”。

一、业务实体

业务实体实际上就是计算机系统中的一种对象,这种对象中包含了一系列用于操作关键数据的业务逻辑。这些实体对象要么直接包含关键业务数据,要么可以很容易地访问这些数据。业务实体的接口原则则是由那些实现关键业务逻辑、操作关键业务数据的函数组成的。

二、用例

并不是所有的业务逻辑都是一个纯粹的业务实体。

用例本身是一个对象,该对象中包含了一个或多个实现了特定应用情景的业务逻辑函数。除此之外,用例对象中也包含了输入数据、输出数据以及相关业务实体的引用,以方便调用。

业务实体并不会知道是哪个业务用例在控制它们,这也是依赖反转原则的另一个应用情景。也就是像业务实体这样的高层概念是无须了解像用例这样的低层概念的。反之,低层的业务用例却需要了解高层的业务实体。

那么,为什么业务实体属于高层概念,而用例属于低层概念呢?因为用例描述的是一个特定的应用情景,这样一来,用例必然会更靠近系统的输入和输出。而业务实体是一个可以适用于多个应用情景的一般化概念,相对地离系统的输入和输出更远。所以,用例依赖于业务实体,而业务实体并不依赖于用例。

三、请求和响应模型

在通常情况下,用例会接收输入数据,并产生输出数据。但在一个设计良好的架构中,用例对象通常不应该知道数据展现给用户或者其他组件的方式。

文章目录
  1. 一、业务实体
  2. 二、用例
  3. 三、请求和响应模型