-
Notifications
You must be signed in to change notification settings - Fork 17
/
Architecting Applications for the Real World in .NET=Cory House;Note=Erxin.txt
175 lines (120 loc) · 4.39 KB
/
Architecting Applications for the Real World in .NET=Cory House;Note=Erxin.txt
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
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
Architecting Applications for the Real World in .NET=Cory House;Note=Erxin
# introduction
- reference course
building inter application in c#, stiff smith
# the problem
- pragmatic architecture
i will use this everywhere, there is no silver bullet
x is good -> it depends
- what's an expert?
anyone can design a bridge that stands, it takes an engineer to design a bridge that barely stands
- pragmatic
- reason to select an architecture
+ save money
+ save effort
+ save time
+ risk like
to experiment
+ to challenge myself
to improve my resume
- agenda & references
+ three simple goals
context, module 2 pragmatic principles simplicity argument timelines
+ layers, module 3-6
business logic, service, data access presentation layer
+ levels module
contrast extremes, simple vs complex
- references
+ design patterns library by Steve Smith, et al. on Pluralsight
+ pattern of enterprise architecture by Martin Fowler (book)
+ microsoft.net architecting application for the enterprise by dino esposito and andrea saltarello
- assumptions
+ enterprise line-of-business application, both large and small
+ RDBMS database
# real-world architectural thinking
- which should we choose
+ first
coded to interfaces
90% test coverage
rich domain model
service oriented architecture
+ second
no api
no layers
no tests
tightly coupled
- what if i said
+ $ 250k over budget for the first choice
+ customer hated it, or worse, ignored it
+ project funding dried up
- metaphors for architecture selection
+ time to set up ?
+ training
+ necessary tooling?
+ large enough to warrant "prep time"
- more effective, more flexible, most scalable?
+ such as hanmer compare to nailgun
- astronaut assessment, don't make to higher abstraction
- consider complexity
+ coding to an interfaces
+ soa
+ automated testing
+ domain driven design, custom tiler for specify action
+ custom dal
+ layered architecture
- complexity ~= lines of coded, complexity != bad, complexity must be justified
we are paid for solution, not code
- parkinson's low, work expands to fill available time
- simplicity, the art of maximizing the amount of work not done
- consider simplicity
+ do simplest thing that could possible work /KISS
+ agile principles
+ lean principles
+ lean principles
+ 80/20 rule
+ minimum viable product(MVP)
- do simplest thing that could possible work
+ get done sooner
+ eaiser to communicate
+ duplication is obvious, so needs for refactoring are clearer
+ tests are easier to write
+ code is easier to performance tune
http://xp.c2.com/doTheSimplestThingThatCouldPossibleWork.html
- 80/20 rule, get 80% of the benefit from 20% of the features
- get 80% of benefit of automated testing by testing the most important 20%?
- agile manifesto
+ maximize the work not done
+ welcome changing requirements, even late in development
- lean principles
+ eliminate waste, not adding value to the customer, it's likely waste
+ amplify learning
+ decide as late as possible, choice unclear? choose the simple option
+ deliver as fast as possible, ideaarchitecture varies by team
+ empower the team
+ build integrity in , automated testing
+ see the whole
- minimum viable product(MVP)
+ validated learning
what was the response?
what did they like hate?
how much profit?
is this worth scaling
bad assumptions?
do we need to pivot?
+ what we don't care about
scalability
maintenance costs
and often
beauty, code clieanliness, full feature set performance, security if it even actually works
- time line
+ agile architecture, flex one
quality, technical debet
/ \
date--------cost
+ assuming deadline manpower and scope are constan
is debt bad, is the deadline hard
+ hard vs soft deadlines
trade show, published advertising, x-team dependencies, 1st to market or dead
network effects
+ single loud customer, wild guess, salesman misspoke, ms project said so
# business logic layer