[图解]企业应用架构模式2024新译本讲解13-服务层1

1
00:00:00,150 --> 00:00:05,030
接下来我们来看服务层模式

2
00:00:06,070 --> 00:00:11,740
这也是领域逻辑类型的最后一个模式

3
00:00:13,700 --> 00:00:17,110
我们前面实际上已经见过了，事务脚本

4
00:00:17,240 --> 00:00:19,900
的时候，已经见过了

5
00:00:21,030 --> 00:00:22,960
这里单独拿出来讲

6
00:00:24,220 --> 00:00:26,490
就是说，重点放在它上面

7
00:00:30,680 --> 00:00:32,150
这是书里面的定义

8
00:00:32,920 --> 00:00:37,110
通过一个层……

9
00:00:37,570 --> 00:00:39,570
实际上这个就类似于

10
00:00:39,580 --> 00:00:42,050
我们分析里面的控制类

11
00:00:44,660 --> 00:00:47,190
为什么需要这样一个层

12
00:00:48,540 --> 00:00:49,210
什么叫层

13
00:00:49,220 --> 00:00:54,920
我们前面也讲，类似性质的类的集合放一起

14
00:00:55,730 --> 00:00:57,540
因为它是一个不严谨的概念

15
00:00:57,550 --> 00:00:59,660
就是差不多的类的集合

16
00:01:01,070 --> 00:01:03,530
放一个包里面，类似这样

17
00:01:06,610 --> 00:01:08,300
为什么需要这样一个

18
00:01:08,650 --> 00:01:12,960
就是说，我们的核心域逻辑

19
00:01:14,570 --> 00:01:16,120
这是我的说法了

20
00:01:16,130 --> 00:01:17,880
书里面讲的不是这样讲

21
00:01:17,890 --> 00:01:19,800
说有领域逻辑、应用逻辑

22
00:01:20,070 --> 00:01:22,000
但实际上你说应用逻辑

23
00:01:22,010 --> 00:01:24,530
难道就不是领域逻辑的一部分吗

24
00:01:24,540 --> 00:01:24,890
是的

25
00:01:25,660 --> 00:01:27,530
我们应该说都是领域逻辑

26
00:01:28,100 --> 00:01:29,660
只不过有的是类级别的

27
00:01:33,590 --> 00:01:34,820
实体类级别的

28
00:01:34,830 --> 00:01:39,430
也就是说，它所有的逻辑

29
00:01:39,440 --> 00:01:41,320
能封装在类的操作里面

30
00:01:42,540 --> 00:01:43,860
包括状态机里面

31
00:01:45,030 --> 00:01:47,390
当然这个类，可能会组合其他类

32
00:01:50,070 --> 00:01:52,430
也就是说，责任分配给它

33
00:01:52,440 --> 00:01:53,830
它能够自己搞定

34
00:01:55,640 --> 00:01:58,000
从核心域的角度上面

35
00:01:58,010 --> 00:02:01,270
当然，后面还有数据库什么的再说了

36
00:02:02,530 --> 00:02:08,400
这个是类级别的逻辑

37
00:02:09,530 --> 00:02:10,520
大多数的逻辑

38
00:02:10,530 --> 00:02:12,920
都应该封装在类似这样的地方

39
00:02:16,220 --> 00:02:17,380
但是有一些逻辑

40
00:02:17,390 --> 00:02:21,450
它可能跟特定的用例相关的

41
00:02:24,710 --> 00:02:34,540
那么它需要调用很多个类来协作完成

42
00:02:35,230 --> 00:02:38,270
这种很可能不适合放在某一个类里面

43
00:02:38,930 --> 00:02:41,290
那就需要一个类似控制类这样的

44
00:02:41,300 --> 00:02:43,210
应用服务类

45
00:02:44,250 --> 00:02:45,770
来协调它们

46
00:02:46,320 --> 00:02:48,730
这种逻辑就是应用级别逻辑

47
00:02:48,740 --> 00:02:52,770
它是跟用例的控制流相关的

48
00:02:54,610 --> 00:02:59,900
所以命名往往是以用例的名字来命名

49
00:03:01,420 --> 00:03:02,980
或者用例集的名字来命名

50
00:03:02,990 --> 00:03:05,080
我们前面也讲过了

51
00:03:07,470 --> 00:03:12,190
那么它的存在只是为了协调这几个类

52
00:03:12,320 --> 00:03:16,220
也就是说，我们的类本身

53
00:03:18,390 --> 00:03:23,340
它本身如果没有用例的情况下

54
00:03:24,070 --> 00:03:25,360
很可能类本身

55
00:03:25,370 --> 00:03:27,890
可能是孤立的，独立的

56
00:03:29,090 --> 00:03:30,640
之间并没有静态关系

57
00:03:32,110 --> 00:03:32,930
它就摆在那里

58
00:03:34,580 --> 00:03:36,810
只有当你这个用例发生的时候

59
00:03:37,070 --> 00:03:39,630
通过应用服务或者控制类

60
00:03:42,650 --> 00:03:43,840
让它们一起来协作

61
00:03:47,400 --> 00:03:48,120
要是没发生

62
00:03:48,130 --> 00:03:50,600
那么它们可能互相并不知道对方

63
00:03:51,860 --> 00:03:53,010
如果它们知道对方

64
00:03:53,020 --> 00:03:55,050
很可能它们自己就可以协作了

65
00:03:55,420 --> 00:03:57,720
比如说，订单，订单项，商品

66
00:03:57,730 --> 00:04:00,750
它们之间有静态关系的

67
00:04:01,220 --> 00:04:03,380
那时候很可能你发一个消息给订单

68
00:04:03,840 --> 00:04:05,440
订单会自己找订单项

69
00:04:05,450 --> 00:04:06,520
订单项找商品

70
00:04:07,100 --> 00:04:08,170
这事情就做完了

71
00:04:08,420 --> 00:04:10,710
并不需要外面一个类找订单

72
00:04:10,720 --> 00:04:13,470
然后外面一个类再找订单项

73
00:04:13,880 --> 00:04:15,460
外面一个类再找商品

74
00:04:15,470 --> 00:04:21,950
不需要，应用级别的

75
00:04:22,680 --> 00:04:23,870
有了这样一个类之后

76
00:04:24,650 --> 00:04:29,720
它就使得这个逻辑

77
00:04:30,210 --> 00:04:32,860
就不会放到某个特定的类里面

78
00:04:33,880 --> 00:04:35,170
而是单独独立出来

79
00:04:36,680 --> 00:04:40,710
原来那些类，它就有了更多复用的可能

80
00:04:41,290 --> 00:04:43,020
如果说你某个用例

81
00:04:43,030 --> 00:04:45,340
特有的流程的信息

82
00:04:45,350 --> 00:04:46,660
就放在某个类里面

83
00:04:49,290 --> 00:04:51,810
那很可能另外一个用例用的时候

84
00:04:52,340 --> 00:04:53,410
它就会受到影响了

85
00:04:53,420 --> 00:04:54,850
很可能很多是不适合的

86
00:04:54,860 --> 00:04:57,290
那么复用的可能性就降低了

87
00:04:58,960 --> 00:05:00,680
当然，如果说，我们前面讲

88
00:05:00,690 --> 00:05:02,040
如果能够把它变成

89
00:05:03,240 --> 00:05:06,870
确实是某个实体类能够搞定的

90
00:05:09,530 --> 00:05:12,990
那么优先还是放在实体类里面了

91
00:05:14,770 --> 00:05:18,080
但是要注意实体类的这种划分

92
00:05:18,850 --> 00:05:20,170
识别、构造等等

93
00:05:20,180 --> 00:05:23,500
要按照我们特定的规则来完成

94
00:05:24,500 --> 00:05:27,990
不能说我为了尽可能放在实体类里面

95
00:05:28,000 --> 00:05:30,690
我搞一个特别大的实体类

96
00:05:31,790 --> 00:05:33,540
我在实体类里面有100个属性

97
00:05:35,620 --> 00:05:38,140
所以我就取消了前面的服务类

98
00:05:38,150 --> 00:05:40,710
你看，我就一个实体类

99
00:05:41,170 --> 00:05:42,400
这实体类就叫系统

100
00:05:43,900 --> 00:05:46,190
这个系统有100个属性

101
00:05:48,380 --> 00:05:49,820
那是没用的

102
00:05:50,030 --> 00:05:52,560
首先你这个类本身

103
00:05:52,570 --> 00:05:54,720
它要按照我们的一定的

104
00:05:54,730 --> 00:05:56,320
这种规则来建立

105
00:05:56,870 --> 00:05:59,860
还是我们前面讲的，没有冗余的规则

106
00:06:00,480 --> 00:06:02,310
包括前面的课程也说过了

107
00:06:03,170 --> 00:06:04,570
把各种各样信息

108
00:06:04,580 --> 00:06:06,770
按照没有冗余这种方式

109
00:06:07,970 --> 00:06:09,160
识别和建模

110
00:06:10,750 --> 00:06:13,540
然后需要各种形式的信息的时候

111
00:06:13,550 --> 00:06:17,170
通过集合运算计算出来

112
00:06:17,820 --> 00:06:19,060
而不是搞一个很大的

113
00:06:19,470 --> 00:06:21,950
里面有很多冗余

114
00:06:24,040 --> 00:06:28,800
那么这又是另外一种遮羞布

115
00:06:29,090 --> 00:06:31,990
他说，你看，我没有用服务类

116
00:06:32,780 --> 00:06:35,110
我就放实体类里面，实体类很大

117
00:06:35,120 --> 00:06:35,870
不对

118
00:06:38,410 --> 00:06:44,090
好，这是我们说的服务层里面的道理