[图解]企业应用架构模式2024新译本讲解08-领域模型1

1
00:00:00,250 --> 00:00:04,850
接下来，我们来看领域模型这个模式

2
00:00:06,690 --> 00:00:15,100
这也是领域逻辑模式类型里面的一个

3
00:00:15,430 --> 00:00:19,440
定义，合并*****领域对象模型

4
00:00:23,120 --> 00:00:27,990
这个实际上就是真正的面向对象实现的模式了

5
00:00:31,410 --> 00:00:33,340
前面讲的事务脚本也好

6
00:00:33,350 --> 00:00:34,730
表模块也好

7
00:00:36,320 --> 00:00:39,940
它实际上是假的面向对象

8
00:00:40,590 --> 00:00:44,790
就算它表面上有一个类，什么合同产品等等

9
00:00:45,520 --> 00:00:48,340
但实际上它的行为和数据并不是结合的

10
00:00:51,570 --> 00:00:56,090
而只有这个实现方式，算得上

11
00:00:56,100 --> 00:00:58,050
是真正的面向对象实现

12
00:00:59,870 --> 00:01:04,990
但是领域模型这个词它是一个造词

13
00:01:06,270 --> 00:01:08,270
Martin Fowler用这个词来描述

14
00:01:08,280 --> 00:01:10,030
这样一种实现的模式

15
00:01:10,630 --> 00:01:11,470
实际上这个就是一个

16
00:01:11,480 --> 00:01:17,490
实现我们分析模型的一种模式

17
00:01:17,500 --> 00:01:22,200
你可以把它实现成假的面向对象

18
00:01:22,210 --> 00:01:24,720
也可以实现成真的面向对象

19
00:01:27,940 --> 00:01:28,940
而这个词本身

20
00:01:28,950 --> 00:01:32,020
它在别的地方还有另外的含义

21
00:01:32,030 --> 00:01:35,380
比如说，描述领域逻辑的模型

22
00:01:36,180 --> 00:01:40,790
比如，类图来描述一个物流的领域的模型

23
00:01:41,320 --> 00:01:43,890
用状态机图来描述物流领域的

24
00:01:44,370 --> 00:01:48,270
另外的概念的之间的关系

25
00:01:51,040 --> 00:01:53,570
所以造词造成了混乱

26
00:01:54,860 --> 00:01:57,530
这个地方，模式命名用得不好

1
00:00:01,450 --> 00:00:04,090
领域模型这样一种

2
00:00:04,100 --> 00:00:06,050
领域逻辑的一种实现模式

3
00:00:06,930 --> 00:00:08,620
优缺点，Fowler在书里面

4
00:00:08,630 --> 00:00:10,550
也给出来了

5
00:00:12,890 --> 00:00:17,590
当然译文在这里有一些修正

6
00:00:18,800 --> 00:00:21,910
先说缺点，就是说，因为

7
00:00:21,920 --> 00:00:22,790
这个责任

8
00:00:24,230 --> 00:00:26,260
它是分布在很多个类里面的

9
00:00:28,490 --> 00:00:31,260
所以你阅读程序的时候

10
00:00:32,290 --> 00:00:39,360
得花费时间在一个个类间跳转

11
00:00:40,030 --> 00:00:43,460
一会我们看示例的程序的时候

12
00:00:44,230 --> 00:00:48,040
我们也可以看到，随着一步一步的执行

13
00:00:48,050 --> 00:00:50,560
它就从这个类跳那个类

14
00:00:53,540 --> 00:00:56,340
所以如果你用序列图把它画出来的话

15
00:00:57,470 --> 00:00:58,120
就可以看到

16
00:00:58,250 --> 00:01:01,430
它有很多类在上面交互

17
00:01:02,390 --> 00:01:06,790
这个序列图比较庞大

18
00:01:06,800 --> 00:01:11,870
从横向上来说，往横里面扩展是比较大的

19
00:01:14,990 --> 00:01:16,530
但是他也说了优点

20
00:01:17,620 --> 00:01:21,060
一旦相关的逻辑变复杂了

21
00:01:23,710 --> 00:01:27,980
这种做法就避免了冗余代码

22
00:01:28,690 --> 00:01:30,810
避免了冗余，还有减少了耦合

23
00:01:31,530 --> 00:01:34,320
这是优点

24
00:01:40,890 --> 00:01:43,370
同样的，我们来看一下案例

25
00:01:44,380 --> 00:01:47,040
案例，书上仍然是用的

26
00:01:47,050 --> 00:01:49,310
收入确认这个案例

27
00:01:51,780 --> 00:01:53,570
同样，也做了一些修正

28
00:01:54,100 --> 00:01:55,250
译文也做了修正

29
00:01:56,910 --> 00:01:57,960
我们看这个类图

30
00:01:58,750 --> 00:02:05,560
你看，这个类图上的合同、产品、收入确认

31
00:02:08,500 --> 00:02:10,680
这些都是有属性的

32
00:02:10,980 --> 00:02:11,980
产品好像没有

33
00:02:11,990 --> 00:02:14,500
实际上应该是有名称什么的，这里没画出来

34
00:02:16,720 --> 00:02:19,280
就算没有属性，关联实际上也是属性

35
00:02:20,220 --> 00:02:21,940
然后，合同知道产品

36
00:02:23,600 --> 00:02:24,480
知道收入确认

37
00:02:24,890 --> 00:02:29,280
产品知道，你看，这里有一个收入确认的策略

38
00:02:32,070 --> 00:02:33,580
所以，它这里采用了

39
00:02:34,620 --> 00:02:37,140
GOF里面的一个策略模式

40
00:02:40,570 --> 00:02:43,080
策略模式是什么意思

41
00:02:43,090 --> 00:02:45,520
实际上就相当于把泛化关系

42
00:02:46,660 --> 00:02:49,770
推迟到下一个级别

43
00:02:54,970 --> 00:02:57,450
你看，这个产品这里没有泛化关系

44
00:02:57,970 --> 00:02:59,660
本来这里可以有泛化关系

45
00:02:59,670 --> 00:03:01,180
产品下面有子类

46
00:03:02,150 --> 00:03:03,290
分三个子类

47
00:03:03,910 --> 00:03:05,990
什么文档处理器

48
00:03:07,100 --> 00:03:09,630
电子表格、数据库

49
00:03:09,640 --> 00:03:12,040
就是我们前面讲的

50
00:03:13,310 --> 00:03:14,840
类似于微软里面的Word

51
00:03:15,650 --> 00:03:20,150
Excel，Access，但是这里没有

52
00:03:21,660 --> 00:03:23,260
它把它推迟到这里来了

53
00:03:26,030 --> 00:03:27,080
泛化关系放在这里

54
00:03:28,590 --> 00:03:31,100
就相当于把不同的地方

55
00:03:31,920 --> 00:03:35,770
把它分离到一个

56
00:03:35,780 --> 00:03:39,900
被它关联到的一个类里面

57
00:03:41,320 --> 00:03:41,780
推迟

58
00:03:48,180 --> 00:03:49,400
那么这里就意味着什么

59
00:03:49,410 --> 00:03:57,670
你看，这里产品关联到策略

60
00:03:57,680 --> 00:03:59,150
或者说，拥有一个策略

61
00:04:00,720 --> 00:04:01,250
意味着什么

62
00:04:01,260 --> 00:04:05,330
这个产品是什么产品你是不知道的

63
00:04:06,580 --> 00:04:08,260
前面产品类型什么的也没有了

64
00:04:09,920 --> 00:04:11,150
实际上这个策略

65
00:04:11,160 --> 00:04:13,150
就起到了一个类型的作用

66
00:04:15,650 --> 00:04:17,250
所以后面我们还会说到

67
00:04:17,420 --> 00:04:19,770
实际上这个可以改成类型

68
00:04:19,780 --> 00:04:23,340
相当于我们彩色建模里面的描述类

69
00:04:23,430 --> 00:04:30,320
我们还可以看到

70
00:04:30,330 --> 00:04:33,230
你看，合同依赖于产品

71
00:04:36,030 --> 00:04:38,820
单向关联，合同依赖于产品

72
00:04:40,190 --> 00:04:42,800
合同拥有一个产品

73
00:04:45,770 --> 00:04:49,330
但是你看，这个产品这里

74
00:04:49,340 --> 00:04:53,150
有个计算收入确认的一个操作

75
00:04:53,160 --> 00:04:56,340
这里面又有一个合同作为参数

76
00:04:58,020 --> 00:05:01,350
实际上，产品又依赖于合同

77
00:05:01,360 --> 00:05:03,150
只不过依赖是比较弱的依赖

78
00:05:04,130 --> 00:05:06,610
这是比较强的，静态的，这个是动态的

79
00:05:11,180 --> 00:05:15,240
实际上这个分配方式，这样分配责任其实也不是很好

80
00:05:16,610 --> 00:05:17,760
后面我们再说这个问题

81
00:05:17,770 --> 00:05:18,760
我们先看这个案例

82
00:05:20,340 --> 00:05:23,420
我们再说一下策略模式

83
00:05:23,430 --> 00:05:24,460
我们前面讲

84
00:05:24,470 --> 00:05:26,100
软件方法的时候也说过了

85
00:05:27,110 --> 00:05:29,390
什么策略、模板方法等等

86
00:05:30,260 --> 00:05:32,820
实际上只是换汤不换药，虽然也有用

87
00:05:33,250 --> 00:05:34,570
但只是换汤不换药

88
00:05:34,890 --> 00:05:37,920
它仍然把这个变化放在行为那里

89
00:05:37,930 --> 00:05:40,300
只不过把这个行为的变化

90
00:05:40,310 --> 00:05:42,620
延迟到了，放到策略里面去

91
00:05:43,670 --> 00:05:44,940
这样显得灵活一点

92
00:05:45,620 --> 00:05:47,220
但实际上还是换汤不换药

93
00:05:48,800 --> 00:05:50,100
真正好的做法

94
00:05:50,110 --> 00:05:53,010
应该是把里面的规律

95
00:05:53,930 --> 00:05:56,520
变成概念之间的映射

96
00:05:58,410 --> 00:06:01,500
我们后面还会再说，怎么做比较好，这个案例

97
00:06:02,570 --> 00:06:06,360
把更多的概念提炼出来

98
00:06:07,120 --> 00:06:12,060
然后通过类之间的这种运算得到结果

99
00:06:12,070 --> 00:06:15,360
而不是说把变化写在代码里面

100
00:06:15,370 --> 00:06:16,040
没有必要

101
00:06:17,060 --> 00:06:18,870
除非没办法了

102
00:06:20,490 --> 00:06:21,890
规律太复杂了

103
00:06:22,790 --> 00:06:24,420
通过这种概念的映射

104
00:06:24,870 --> 00:06:26,670
解决不了，才放进来

105
00:06:27,550 --> 00:06:29,880
我们前面的课程也说过很多遍了

106
00:06:29,890 --> 00:06:32,130
尽量先在属性上做变化

107
00:06:32,790 --> 00:06:33,530
实在不行了

108
00:06:33,540 --> 00:06:43,110
再行为变化，策略这里，有两个子类

109
00:06:43,200 --> 00:06:46,270
一个是完全收入确认策略

110
00:06:46,780 --> 00:06:50,160
就一次性的，进来多少就马上入账

111
00:06:50,170 --> 00:06:52,080
这是分段的，分三段

112
00:06:52,700 --> 00:06:55,610
那三段这里有两个属性

113
00:06:55,620 --> 00:06:58,450
一个是第一段的偏移

114
00:06:58,460 --> 00:07:03,070
就是隔几天再搞一段，隔几天再搞一段

115
00:07:03,080 --> 00:07:05,710
比如说，分三段

116
00:07:07,020 --> 00:07:08,660
现在有1万块进来

117
00:07:10,630 --> 00:07:12,830
肯定有一部分是马上入账的

118
00:07:15,410 --> 00:07:16,720
第二部分什么时候入账

119
00:07:16,730 --> 00:07:18,390
就这个时间来定了

120
00:07:20,360 --> 00:07:21,390
第三部分什么时候入账

121
00:07:21,400 --> 00:07:26,260
就这个时间来定，30，30天以后入账

122
00:07:26,920 --> 00:07:34,560
60，就60天以后入第二笔账，这个地方

123
00:07:37,860 --> 00:07:39,610
下面我们来看一下代码