1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
1
00:00:00,100 --> 00:00:02,620
And I want to conclude this lesson with three takeaway
2
00:00:02,620 --> 00:00:06,190
messages. The first one is that having an effective architecture is
3
00:00:06,190 --> 00:00:09,450
fundamental in a software project. Or as I say here,
4
00:00:09,450 --> 00:00:13,050
a great architecture is a ticket to a successful project. To
5
00:00:13,050 --> 00:00:15,290
put it in a different way, although a great architecture
6
00:00:15,290 --> 00:00:17,940
does not guarantee that your project will be successful, having a
7
00:00:17,940 --> 00:00:21,930
poor architecture will make it much more difficult for your project
8
00:00:21,930 --> 00:00:25,280
to be successful. The second message is that an architecture cannot
9
00:00:25,280 --> 00:00:28,120
come about in a vacuum. You need to understand
10
00:00:28,120 --> 00:00:30,550
the domain of the problem that you're trying to solve
11
00:00:30,550 --> 00:00:33,480
in order to define an architectural solution that fits the
12
00:00:33,480 --> 00:00:37,220
characteristics of the problem. So a great architecture reflects a
13
00:00:37,220 --> 00:00:40,500
deep understanding of the problem domain. And finally, a great
14
00:00:40,500 --> 00:00:44,630
architecture is likely to combine aspects of several simpler architectures.
15
00:00:44,630 --> 00:00:47,880
It is typical for engineers to see problems that are
16
00:00:47,880 --> 00:00:50,590
new, but such that parts of the problems have already
17
00:00:50,590 --> 00:00:53,540
been solved by someone else. An effective engineer should
18
00:00:53,540 --> 00:00:56,270
therefore, first of all, know what is out there,
19
00:00:56,270 --> 00:00:59,760
know the solution space. Second, an engineer should understand
20
00:00:59,760 --> 00:01:02,420
what has worked well and what has failed miserably in
21
00:01:02,420 --> 00:01:05,870
similar occasions in the past. And finally, an effective
22
00:01:05,870 --> 00:01:10,100
engineer should be able to suitably combine existing solutions appropriately
23
00:01:10,100 --> 00:01:12,870
to come up with an effective overall solution for
24
00:01:12,870 --> 00:01:15,750
the specific problem at hand. And this is just as
25
00:01:15,750 --> 00:01:18,960
true in the context of software architectures. When defining a software
26
00:01:18,960 --> 00:01:22,330
architecture, you should innovate only as much as you need to and
27
00:01:22,330 --> 00:01:24,850
reuse as much as you can. As we said early in the
28
00:01:24,850 --> 00:01:27,770
lesson, by doing so, that is, by innovating only as much as
29
00:01:27,770 --> 00:01:30,100
you need to and reusing as much as you can, you will
30
00:01:30,100 --> 00:01:32,960
be able to avoid reinventing the wheel. You will be able to
31
00:01:32,960 --> 00:01:37,320
choose the right solution to known problems. And identify suitable solutions for
32
00:01:37,320 --> 00:01:40,925
new problems. So ultimately, you will be able to realize an effective
33
00:01:40,925 --> 00:01:44,080
software architecture that will help the success of your project.
|
