INDEX
Numbers
3DBB shared memory system, Craft Dispatch System archaeology project, 363 [part0051.html#page_363]
4-TEL, archaeology projects
BOSS, 351 [part0051.html#page_351]–352 [part0051.html#page_352]
C language, 349 [part0051.html#page_349]–351 [part0051.html#page_351]
DLU/DRU, 354 [part0051.html#page_354]–356 [part0051.html#page_356]
overview of, 339 [part0051.html#page_339]–344 [part0051.html#page_344]
pCCU, 352 [part0051.html#page_352]–354 [part0051.html#page_354]
SAC (service area computer), 344 [part0051.html#page_344]–349 [part0051.html#page_349]
VRS, 357 [part0051.html#page_357]–359 [part0051.html#page_359]
8085 computer, archaeological projects
4-TEL, 341 [part0051.html#page_341]
BOSS, 351 [part0051.html#page_351]
C language and, 349 [part0051.html#page_349]–351 [part0051.html#page_351]
DLU/DRU, 356 [part0051.html#page_356]
8086 Intel microcomputer, SAC archaeology project, 347 [part0051.html#page_347]–348 [part0051.html#page_348]
A
Abstract classes
conclusion, 132 [part0027.html#page_132]
Dependency Inversion Principle and, 87 [part0023.html#page_87]
leftover in Zone of Uselessness, 129 [part0027.html#page_129]–130 [part0027.html#page_130]
placing high-level policy, 126 [part0027.html#page_126]–128 [part0027.html#page_128]
services in Java as set of, 246 [part0041.html#page_246]
Abstract components, 125 [part0027.html#page_125]–126 [part0027.html#page_126]
Abstract Factories, 89 [part0023.html#page_89]–90 [part0023.html#page_90]
Abstractions
principle of stable. See SAP (Stable Abstractions Principle) [part0052.html#idx352]
source code dependencies and, 87 [part0023.html#page_87]
stable, 88 [part0023.html#page_88]–89 [part0023.html#page_89]
Access modifiers, architectural packages, 316 [part0049.html#page_316]–319 [part0049.html#page_319]
Accidental duplication, 154 [part0030.html#page_154]–155 [part0030.html#page_155]
Actors, 62 [part0019.html#page_62]–65 [part0019.html#page_65]
Address segments, relocatable binaries, 99 [part0025.html#page_99]–100 [part0025.html#page_100]
ADP (Acyclic Dependencies Principle)
breaking cycle, 117 [part0027.html#page_117]–118 [part0027.html#page_118]
component dependency graph effected by, 118 [part0027.html#page_118]
effect of cycle in component dependency graph, 115 [part0027.html#page_115]–117 [part0027.html#page_117]
eliminating dependency cycles, 113 [part0027.html#page_113]–115 [part0027.html#page_115]
jitters, 118 [part0027.html#page_118]
overview of, 112 [part0027.html#page_112]
weekly build, 112 [part0027.html#page_112]–113 [part0027.html#page_113]
Aluminum die-cast monitoring, archaeology project, 338 [part0051.html#page_338]–339 [part0051.html#page_339]
APIs, testing, 252 [part0042.html#page_252]–253 [part0042.html#page_253]
App-titude test, 258 [part0043.html#page_258]–261 [part0043.html#page_261]
Application-specific business rules, use cases, 192 [part0034.html#page_192]–193 [part0034.html#page_193], 204 [part0036.html#page_204]
Architects
goal to minimize human resources, 160 [part0031.html#page_160]
registry exam archaeology project, 370 [part0051.html#page_370]–373 [part0051.html#page_373]
separate details from policy, 142 [part0029.html#page_142]
Architecture
clean. See Clean architecture [part0052.html#idx62]
clean embedded. See Clean embedded architecture [part0052.html#idx63]
design vs., 4 [part0011.html#page_4]
in DLU/DRU archaeology project, 356 [part0051.html#page_356]
Eisenhower’s matrix of importance vs. urgency, 16 [part0012.html#page_16]–17 [part0012.html#page_17]
getting software right, 2 [part0010.html#page_2]
immutability and, 52 [part0017.html#page_52]
independence. See Independence [part0052.html#idx205]
ISP and, 86 [part0022.html#page_86]
LSP and, 80 [part0021.html#page_80]
plugin, 170 [part0031.html#page_170]–171 [part0031.html#page_171]
in ROSE archaeology product, 368 [part0051.html#page_368]–370 [part0051.html#page_370]
in SAC archaeology project, 345 [part0051.html#page_345]–347 [part0051.html#page_347]
as senior to function, 18 [part0012.html#page_18]
as software value, 14 [part0012.html#page_14]–15 [part0012.html#page_15]
stability, 122 [part0027.html#page_122]–126 [part0027.html#page_126]
testing, 213 [part0037.html#page_213]
three big concerns in, 24 [part0014.html#page_24]
value of function vs., 15 [part0012.html#page_15]–16 [part0012.html#page_16]
in VRS archaeology project, 358 [part0051.html#page_358]–359 [part0051.html#page_359]
Architecture archaeology projects
4-TEL, 339 [part0051.html#page_339]–344 [part0051.html#page_344]
aluminum die-cast monitoring, 338 [part0051.html#page_338]–339 [part0051.html#page_339]
architects registry exam, 370 [part0051.html#page_370]–373 [part0051.html#page_373]
by author since 1970, 325 [part0051.html#page_325]–326 [part0051.html#page_326]
Basic Operating System and Scheduler, 351 [part0051.html#page_351]–352 [part0051.html#page_352]
C language, 349 [part0051.html#page_349]–351 [part0051.html#page_351]
conclusion, 373 [part0051.html#page_373]
Craft Dispatch System, 361 [part0051.html#page_361]–367 [part0051.html#page_367]
DLU/DRU, 354 [part0051.html#page_354]–356 [part0051.html#page_356]
Electronic Receptionist, 359 [part0051.html#page_359]–361 [part0051.html#page_361]
Laser Trim, 334 [part0051.html#page_334]–338 [part0051.html#page_338]
pCCU, 352 [part0051.html#page_352]–354 [part0051.html#page_354]
ROSE product, 368 [part0051.html#page_368]–370 [part0051.html#page_370]
service area computer, 344 [part0051.html#page_344]–349 [part0051.html#page_349]
Union Accounting system, 326 [part0051.html#page_326]–334 [part0051.html#page_334]
VRS, 357 [part0051.html#page_357]–359 [part0051.html#page_359]
Architecture, defining
conclusion, 146 [part0029.html#page_146]
deployment, 138 [part0029.html#page_138]
development, 137 [part0029.html#page_137]–138 [part0029.html#page_138]
device independence, 142 [part0029.html#page_142]–143 [part0029.html#page_143]
junk mail example, 144 [part0029.html#page_144]–145 [part0029.html#page_145]
keeping options open, 140 [part0029.html#page_140]–142 [part0029.html#page_142]
maintenance, 139 [part0029.html#page_139]–140 [part0029.html#page_140]
operation, 138 [part0029.html#page_138]–139 [part0029.html#page_139]
physical addressing example, 145 [part0029.html#page_145]–146 [part0029.html#page_146]
understanding, 135 [part0029.html#page_135]–137 [part0029.html#page_137]
Architecture, screaming
about the web, 197 [part0035.html#page_197]–198 [part0035.html#page_198]
conclusion, 199 [part0035.html#page_199]
frameworks as tools, not ways of life, 198 [part0035.html#page_198]
overview of, 195 [part0035.html#page_195]–196 [part0035.html#page_196]
purpose of, 197 [part0035.html#page_197]
testable architectures, 198 [part0035.html#page_198]
theme, 196 [part0035.html#page_196]–197 [part0035.html#page_197]
Archives, as aggregation of components, 96 [part0025.html#page_96]
Artifacts, OCP, 70 [part0020.html#page_70]
ASC Tabulating, Union Accounting archaeology project, 326 [part0051.html#page_326]–334 [part0051.html#page_334]
Assignment, and functional programming, 23 [part0014.html#page_23]
Asymmetric marriage, to framework authors, 292 [part0047.html#page_292]–293 [part0047.html#page_293]
Authors, framework, 292 [part0047.html#page_292]–293 [part0047.html#page_293]
Automated systems, business rules, 191 [part0034.html#page_191]–192 [part0034.html#page_192]
B
Base classes, frameworks, 293 [part0047.html#page_293]
BCE system architecture, 202 [part0036.html#page_202]
Beck, Kent, 258 [part0043.html#page_258]–261 [part0043.html#page_261]
Behavior (function)
architecture supports system, 137 [part0029.html#page_137], 148 [part0030.html#page_148]
Eisenhower’s matrix of importance vs. urgency, 16 [part0012.html#page_16]–17 [part0012.html#page_17]
fighting for seniority of architecture over function, 18 [part0012.html#page_18]
keeping options open, 140 [part0029.html#page_140]–142 [part0029.html#page_142]
as software value, 14 [part0012.html#page_14]
value of function vs. architecture, 15 [part0012.html#page_15]–16 [part0012.html#page_16]
Binaries, relocatability, 99 [part0025.html#page_99]–100 [part0025.html#page_100]
Booch, Grady
introduction to, 366 [part0051.html#page_366]
working for, 367 [part0051.html#page_367]
working on ROSE product, 368 [part0051.html#page_368]–369 [part0051.html#page_369]
BOSS (Basic Operating System and Scheduler)
archaeology project, 351 [part0051.html#page_351]–352 [part0051.html#page_352]
in DLU/DRU archaeology project, 356 [part0051.html#page_356]
Boundaries
in 4 [part0011.html#page_4]-TEL archaeology project, 340 [part0051.html#page_340]–341 [part0051.html#page_341]
conclusion, 173 [part0031.html#page_173]
dividing services into components, 246 [part0041.html#page_246]
in Electronic Receptionist archaeology project, 361 [part0051.html#page_361]
FitNesse program, 163 [part0031.html#page_163]–165 [part0031.html#page_165]
input and output, 169 [part0031.html#page_169]–170 [part0031.html#page_170]
in Laser Trim archaeology project, 338 [part0051.html#page_338]
layers and. See Layers and boundaries [part0052.html#idx231]
overview of, 159 [part0031.html#page_159]–160 [part0031.html#page_160]
partial, 218 [part0038.html#page_218]–220 [part0038.html#page_220]
plugin architecture, 170 [part0031.html#page_170]–171 [part0031.html#page_171]
plugin argument, 172 [part0031.html#page_172]–173 [part0031.html#page_173]
sad stories of architectural failures, 160 [part0031.html#page_160]–163 [part0031.html#page_163]
services as function calls across, 240 [part0041.html#page_240]
test, 249 [part0042.html#page_249]–253 [part0042.html#page_253]
Union Accounting system archaeology project, 333 [part0051.html#page_333]–334 [part0051.html#page_334]
which lines to draw, and when, 165 [part0031.html#page_165]–169 [part0031.html#page_169]
Boundary anatomy
boundary crossing, 176 [part0032.html#page_176]
conclusion, 181 [part0032.html#page_181]
deployment components, 178 [part0032.html#page_178]–179 [part0032.html#page_179]
dreaded monolith, 176 [part0032.html#page_176]–178 [part0032.html#page_178]
local processes, 179 [part0032.html#page_179]–180 [part0032.html#page_180]
services, 180 [part0032.html#page_180]–181 [part0032.html#page_181]
threads, 179 [part0032.html#page_179]
Boundary crossing
in clean architecture, 206 [part0036.html#page_206]
clean architecture scenario, 207 [part0036.html#page_207]–208 [part0036.html#page_208]
creating appropriate, 176 [part0032.html#page_176]
Dependency Rule for data in, 207 [part0036.html#page_207]
Breaking cycle, Acyclic Dependencies Principle, 117 [part0027.html#page_117]–118 [part0027.html#page_118]
Business managers
Eisenhower’s matrix of importance vs. urgency, 17 [part0012.html#page_17]
preference for function vs. architecture, 15 [part0012.html#page_15]–16 [part0012.html#page_16]
Business rules
boundaries between GUI and, 169 [part0031.html#page_169]–170 [part0031.html#page_170]
clean architecture for, 202 [part0036.html#page_202]–203 [part0036.html#page_203]
conclusion, 194 [part0034.html#page_194]
creating Entities, 190 [part0034.html#page_190]–191 [part0034.html#page_191]
decoupling from UI, 287 [part0046.html#page_287]–289 [part0046.html#page_289]
decoupling layers, 152 [part0030.html#page_152]–153 [part0030.html#page_153]
decoupling use cases, 153 [part0030.html#page_153]
designing for testability, 251 [part0042.html#page_251]
in Hunt the Wumpus adventure game, 222 [part0039.html#page_222]–223 [part0039.html#page_223]
independent developability, 47 [part0016.html#page_47]
keeping close to data, 67 [part0019.html#page_67]
plugging into, 170 [part0031.html#page_170]–173 [part0031.html#page_173]
policy statements calculating, 184 [part0033.html#page_184]
request/response models and, 193 [part0034.html#page_193]–194 [part0034.html#page_194]
in SAC archaeology project, 346 [part0051.html#page_346]–347 [part0051.html#page_347]
separating components with boundary lines, 165 [part0031.html#page_165]–169 [part0031.html#page_169]
understanding, 189 [part0034.html#page_189]–190 [part0034.html#page_190]
use cases for, 191 [part0034.html#page_191]–193 [part0034.html#page_193], 204 [part0036.html#page_204]
C
C++ language
inheritance in, 40 [part0016.html#page_40]
learning, 366 [part0051.html#page_366]
marrying STL framework in, 293 [part0047.html#page_293]
polymorphism in, 42 [part0016.html#page_42]
ROSE application, 369 [part0051.html#page_369]–370 [part0051.html#page_370]
weakening encapsulation, 36 [part0016.html#page_36]–37 [part0016.html#page_37]
C language
BOSS archaeology project using, 351 [part0051.html#page_351]–352 [part0051.html#page_352]
DLU/DRU archaeology project using, 356 [part0051.html#page_356]
encapsulation in, 34 [part0016.html#page_34]–36 [part0016.html#page_36]
inheritance in, 38 [part0016.html#page_38]–40 [part0016.html#page_40]
polymorphism in, 40 [part0016.html#page_40]–42 [part0016.html#page_42]
redesigning SAC in, 347 [part0051.html#page_347]–348 [part0051.html#page_348]
C language, archaeology project, 349 [part0051.html#page_349]–351 [part0051.html#page_351]
C# programming language
abstract components in, 125 [part0027.html#page_125]
dependency inversion, 45 [part0016.html#page_45]
using statements for dependencies, 184 [part0033.html#page_184]
weakening encapsulation, 36 [part0016.html#page_36]–37 [part0016.html#page_37]
C Programming Language (Kernighan & Ritchie), 351 [part0051.html#page_351]
C4 software architecture model, 314 [part0049.html#page_314]–315 [part0049.html#page_315]
Carew, Mike, 356 [part0051.html#page_356]
CASE (Computer Aided Software Engineering) tool, 368 [part0051.html#page_368]
Case study. See Video sales case study [part0052.html#idx434]
Cathode ray tube (CRT) terminals, Union Accounting archaeology project, 328 [part0051.html#page_328]–329 [part0051.html#page_329]
CCP (Common Closure Principle)
decoupling layers, 152 [part0030.html#page_152]
grouping policies into components, 186 [part0033.html#page_186]–187 [part0033.html#page_187]
keeping changes localized, 118 [part0027.html#page_118]
overview of, 105 [part0026.html#page_105]–107 [part0026.html#page_107]
Stable Dependencies Principle and, 120 [part0027.html#page_120]
tension diagram, 108 [part0026.html#page_108]–110 [part0026.html#page_110]
CCU/CMU (COLT control unit/COLT measurement unit), pCCU archaeology project, 353 [part0051.html#page_353]–354 [part0051.html#page_354]
CDS (Craft Dispatch System), archaeology project
overview of, 361 [part0051.html#page_361]–363 [part0051.html#page_363]
Central office line testers. See COLTs (central office line testers) [part0052.html#idx71]
Central offices (COs), 4 [part0011.html#page_4]-TEL archaeology project, 339 [part0051.html#page_339]–340 [part0051.html#page_340]
Change, ease of software, 14 [part0012.html#page_14]–15 [part0012.html#page_15]
Church, Alonzo, 22 [part0014.html#page_22]–23 [part0014.html#page_23], 50 [part0017.html#page_50]
CICS-COBOL program, aluminum die-cast archaeology project, 339 [part0051.html#page_339]
Classes
abstract. See Abstract classes [part0052.html#idx5]
Common Reuse Principle, 107 [part0026.html#page_107]–108 [part0026.html#page_108]
DIP and, 89 [part0023.html#page_89]
LSP use in guiding inheritance, 78 [part0021.html#page_78]
partitioning processes into, 71 [part0020.html#page_71]–72 [part0020.html#page_72]
Reuse/Release Equivalence Principle, 105 [part0026.html#page_105]
SRP examples, 67 [part0019.html#page_67]
Clean architecture
characteristics of, 201 [part0036.html#page_201]–203 [part0036.html#page_203]
conclusion, 209 [part0036.html#page_209]
Dependency Rule, 203 [part0036.html#page_203]–207 [part0036.html#page_207]
frameworks tend to violate, 293 [part0047.html#page_293]
typical scenario, 208 [part0036.html#page_208]
using layers and boundaries, 223 [part0039.html#page_223]–226 [part0039.html#page_226]
Clean embedded architecture
app-titude test, 258 [part0043.html#page_258]–261 [part0043.html#page_261]
conclusion, 273 [part0043.html#page_273]
don’t reveal hardware details to user of HAL, 265 [part0043.html#page_265]–269 [part0043.html#page_269]
DRY conditional compilation directives, 272 [part0043.html#page_272]
hardware is detail, 263 [part0043.html#page_263]–264 [part0043.html#page_264]
is testable embedded architecture, 262 [part0043.html#page_262]
layers, 262 [part0043.html#page_262]–263 [part0043.html#page_263]
operating system is detail, 269 [part0043.html#page_269]–271 [part0043.html#page_271]
overview of, 255 [part0043.html#page_255]–258 [part0043.html#page_258]
programming to interfaces and substitutability, 271 [part0043.html#page_271]–272 [part0043.html#page_272]
target-hardware bottleneck, 261 [part0043.html#page_261]
Cleancoders.com [http://Cleancoders.com], 297 [part0048.html#page_297]
Clear Communications, 364 [part0051.html#page_364]–367 [part0051.html#page_367]
phone call, 367 [part0051.html#page_367]
setup, 366 [part0051.html#page_366]
Uncle Bob, 367 [part0051.html#page_367]
Clojure, 50 [part0017.html#page_50]–51 [part0017.html#page_51], 53 [part0017.html#page_53]–54 [part0017.html#page_54]
Codd, Edgar, 278 [part0045.html#page_278]
Code
in aluminum die-cast archaeology project, 338 [part0051.html#page_338]–339 [part0051.html#page_339]
decreasing productivity/increased cost of, 5 [part0011.html#page_5]–7 [part0011.html#page_7]
foolishness of overconfidence, 9 [part0011.html#page_9]–12 [part0011.html#page_12]
rising costs of development payroll, 8 [part0011.html#page_8]–9 [part0011.html#page_9]
in SAC archaeology project, 345 [part0051.html#page_345]
signature of messy, 7 [part0011.html#page_7]–8 [part0011.html#page_8]
source code dependencies. See Source code dependencies [part0052.html#idx379]
Code organization
conclusion, 321 [part0049.html#page_321]
devil is in the details, 315 [part0049.html#page_315]–316 [part0049.html#page_316]
other decoupling modes, 319 [part0049.html#page_319]–320 [part0049.html#page_320]
overview of, 303 [part0049.html#page_303]–304 [part0049.html#page_304]
package by component, 310 [part0049.html#page_310]–315 [part0049.html#page_315]
package by feature, 306 [part0049.html#page_306]–307 [part0049.html#page_307]
package by layer, 304 [part0049.html#page_304]–306 [part0049.html#page_306]
ports and adapters, 308 [part0049.html#page_308]–310 [part0049.html#page_310]
vs. encapsulation, 316 [part0049.html#page_316]–319 [part0049.html#page_319]
Cohesion, Single Responsibility Principle, 63 [part0019.html#page_63]
COLTs (central office line testers)
in 4 [part0011.html#page_4]-TEL archaeology project, 340 [part0051.html#page_340]–344 [part0051.html#page_344]
pCCU archaeology project, 352 [part0051.html#page_352]–354 [part0051.html#page_354]
in service area computer archaeology project, 344 [part0051.html#page_344]–349 [part0051.html#page_349]
Common Closure Principle. See CCP (Common Closure Principle) [part0052.html#idx53]
Common Reuse Principle. See CRP (Common Reuse Principle) [part0052.html#idx104]
Communications
across deployment component boundaries, 179 [part0032.html#page_179]
across local process boundaries, 180 [part0032.html#page_180]
across service boundaries, 180 [part0032.html#page_180]–181 [part0032.html#page_181]
across source-level decoupled boundaries, 178 [part0032.html#page_178]
Conway’s law, 149 [part0030.html#page_149]
as function calls between components in monoliths, 178 [part0032.html#page_178]
in types of decoupling modes, 155 [part0030.html#page_155]–157 [part0030.html#page_157]
Compare and swap algorithm, 54 [part0017.html#page_54]
Compiled languages, 96 [part0025.html#page_96]
Compilers
enforce architectural principles with, 319 [part0049.html#page_319]
location of source code, 97 [part0025.html#page_97]–98 [part0025.html#page_98]
relocatable binaries, 99 [part0025.html#page_99]–100 [part0025.html#page_100]
Component architecture, video sales case study, 300 [part0048.html#page_300]–302 [part0048.html#page_302]
Component-based systems
building scalable, 241 [part0041.html#page_241]
designing services using SOLID, 245 [part0041.html#page_245]–246 [part0041.html#page_246]
function calls, 240 [part0041.html#page_240]
OO approach for cross-cutting concerns, 244 [part0041.html#page_244]–245 [part0041.html#page_245]
Component cohesion
Common Closure Principle, 105 [part0026.html#page_105]–107 [part0026.html#page_107]
Common Reuse Principle, 107 [part0026.html#page_107]–108 [part0026.html#page_108]
conclusion, 110 [part0026.html#page_110]
overview of, 104 [part0026.html#page_104]
Reuse/Release Equivalence Principle, 104 [part0026.html#page_104]–105 [part0026.html#page_105]
tension diagram, 108 [part0026.html#page_108]–110 [part0026.html#page_110]
Component coupling
ADP. See ADP (Acyclic Dependencies Principle) [part0052.html#idx13]
conclusion, 132 [part0027.html#page_132]
Fragile Tests Problem, 251 [part0042.html#page_251]
overview of, 111 [part0027.html#page_111]
Stable Abstractions Principle. See SAP (Stable Abstractions Principle) [part0052.html#idx352]
Stable Dependencies Principle, 120 [part0027.html#page_120]–126 [part0027.html#page_126]
top-down design, 118 [part0027.html#page_118]–119 [part0027.html#page_119]
Component dependency graph
break cycle of components/reinstate as DAG, 117 [part0027.html#page_117]–118 [part0027.html#page_118]
effect of cycle in, 115 [part0027.html#page_115]–117 [part0027.html#page_117]
Component-per-team architecture, 137 [part0029.html#page_137]–138 [part0029.html#page_138]
Components
concrete, 91 [part0023.html#page_91]
deployment of, 178 [part0032.html#page_178]–179 [part0032.html#page_179]
history of, 96 [part0025.html#page_96]–99 [part0025.html#page_99]
linkers, 100 [part0025.html#page_100]–102 [part0025.html#page_102]
overview of, 96 [part0025.html#page_96]
package by, 313 [part0049.html#page_313]–315 [part0049.html#page_315]
partitioning processes into classes/separating classes into, 71 [part0020.html#page_71]–72 [part0020.html#page_72]
principles, 93 [part0024.html#page_93]
relocatability, 99 [part0025.html#page_99]–100 [part0025.html#page_100]
tests as system, 250 [part0042.html#page_250]
Computer Aided Software Engineering (CASE) tool, 368 [part0051.html#page_368]
Concrete components, Dependency Inversion Principle, 91 [part0023.html#page_91]
Concurrent tasks, BOSS archaeology project, 351 [part0051.html#page_351]–352 [part0051.html#page_352]
Concurrent updates, 52 [part0017.html#page_52]–53 [part0017.html#page_53]
Constantine, Larry, 29 [part0015.html#page_29]
Control, flow of. See Flow of control [part0052.html#idx176]
Control structures, program, 27 [part0015.html#page_27]–28 [part0015.html#page_28]
Control, transfer of, 22 [part0014.html#page_22]
Controllers
in clean architecture, 203 [part0036.html#page_203], 205 [part0036.html#page_205]
clean architecture scenario, 207 [part0036.html#page_207]–208 [part0036.html#page_208]
crossing circle boundaries, 206 [part0036.html#page_206]
Conway’s law, 149 [part0030.html#page_149]
Copper wires, pCCU archaeology project, 352 [part0051.html#page_352]–354 [part0051.html#page_354]
Core code, avoid frameworks in, 293 [part0047.html#page_293]
COs (central offices), 4 [part0011.html#page_4]-TEL archaeology project, 339 [part0051.html#page_339]–340 [part0051.html#page_340]
Coupling. See also Component coupling [part0052.html#idx81]
avoid allowing framework, 293 [part0047.html#page_293]
to premature decisions, 160 [part0031.html#page_160]
Craft Dispatch System. See CDS (Craft Dispatch System), archaeology project [part0052.html#idx55]
Critical Business Data, 190 [part0034.html#page_190]–191 [part0034.html#page_191]
Critical Business Rules, 190 [part0034.html#page_190]–193 [part0034.html#page_193]
Cross-cutting concerns
designing services to deal with, 247 [part0041.html#page_247]
object-oriented approach to, 244 [part0041.html#page_244]–245 [part0041.html#page_245]
Crossing data streams, 226 [part0039.html#page_226]
CRP (Common Reuse Principle)
influencing composition of components, 118 [part0027.html#page_118]
overview of, 107 [part0026.html#page_107]–108 [part0026.html#page_108]
tension diagram, 108 [part0026.html#page_108]–110 [part0026.html#page_110]
CRT (cathode ray tube) terminals, Union Accounting archaeology project, 328 [part0051.html#page_328]–329 [part0051.html#page_329]
Cycles
breaking, 117 [part0027.html#page_117]–118 [part0027.html#page_118]
effect of in dependency graph, 115 [part0027.html#page_115]–117 [part0027.html#page_117]
eliminating dependency, 113 [part0027.html#page_113]–115 [part0027.html#page_115]
weekly build issues, 112 [part0027.html#page_112]–113 [part0027.html#page_113]
D
D metric, distance from Main Sequence, 130 [part0027.html#page_130]–132 [part0027.html#page_132]
DAGs (directed acyclic graphs)
architectural framework for policy, 184 [part0033.html#page_184]
breaking cycle of components, 117 [part0027.html#page_117]–118 [part0027.html#page_118]
defined, 114 [part0027.html#page_114]
Dahl, Ole Johan, 22 [part0014.html#page_22]
Data
clean architecture scenario, 207 [part0036.html#page_207]–208 [part0036.html#page_208]
Dependency Rule for crossing boundaries, 207 [part0036.html#page_207]
management concerns in architecture, 24 [part0014.html#page_24]
mappers, 214 [part0037.html#page_214]–215 [part0037.html#page_215]
separating from functions, 66 [part0019.html#page_66]
Data model, database vs., 278 [part0045.html#page_278]
Data storage
in Laser Trim archaeology project, 335 [part0051.html#page_335]
prevalence of database systems due to disks, 279 [part0045.html#page_279]–280 [part0045.html#page_280]
in Union Accounting archaeology project, 327 [part0051.html#page_327]–328 [part0051.html#page_328]
Database
clean architecture independent from, 202 [part0036.html#page_202]
clean architecture scenario, 207 [part0036.html#page_207]–208 [part0036.html#page_208]
creating testable architecture without, 198 [part0035.html#page_198]
decoupling layers, 153 [part0030.html#page_153]
decoupling use cases, 153 [part0030.html#page_153]
Dependency Rule, 205 [part0036.html#page_205]
drawing boundary line between business rules and, 165 [part0031.html#page_165]
gateways, 214 [part0037.html#page_214]
in Hunt the Wumpus adventure game, 222 [part0039.html#page_222]–223 [part0039.html#page_223]
independent developability, 47 [part0016.html#page_47]
leaving options open in development, 141 [part0029.html#page_141], 197 [part0035.html#page_197]
plugin architecture, 171 [part0031.html#page_171]
relational, 278 [part0045.html#page_278]
schema in Zone of Pain, 129 [part0027.html#page_129]
separating components with boundary lines, 165 [part0031.html#page_165]–169 [part0031.html#page_169]
Database is detail
anecdote, 281 [part0045.html#page_281]–283 [part0045.html#page_283]
conclusion, 283 [part0045.html#page_283]
details, 281 [part0045.html#page_281]
if there were no disks, 280 [part0045.html#page_280]–281 [part0045.html#page_281]
overview of, 277 [part0045.html#page_277]–278 [part0045.html#page_278]
performance, 281 [part0045.html#page_281]
relational databases, 278 [part0045.html#page_278]
why database systems are so prevalent, 279 [part0045.html#page_279]–280 [part0045.html#page_280]
DCI system architecture, 202 [part0036.html#page_202]
Deadlocks, from mutable variables, 52 [part0017.html#page_52]
Decoupling
as fallacy of services, 240 [part0041.html#page_240]–241 [part0041.html#page_241]
independent deployment, 154 [part0030.html#page_154], 241 [part0041.html#page_241]
independent development, 153 [part0030.html#page_153]–154 [part0030.html#page_154], 241 [part0041.html#page_241]
kitty problem example, 242 [part0041.html#page_242]–243 [part0041.html#page_243]
layers, 151 [part0030.html#page_151]–152 [part0030.html#page_152]
modes, 153 [part0030.html#page_153], 155 [part0030.html#page_155]–158 [part0030.html#page_158]
OO approach for cross-cutting concerns, 244 [part0041.html#page_244]–245 [part0041.html#page_245]
purpose of testing API, 252 [part0042.html#page_252]–253 [part0042.html#page_253]
source code dependencies, 319 [part0049.html#page_319]
use cases, 152 [part0030.html#page_152]
DeMarco, Tom, 29 [part0015.html#page_29]
Dependencies
ADP. See ADP (Acyclic Dependencies Principle) [part0052.html#idx13]
architectural framework for policy, 184 [part0033.html#page_184]
calculating stability metrics, 123 [part0027.html#page_123]
case study. See Video sales case study [part0052.html#idx434]
Common Reuse Principle and, 107 [part0026.html#page_107]–108 [part0026.html#page_108]
DIP. See DIP (Dependency Inversion Principle) [part0052.html#idx135]
in Laser Trim archaeology project, 338 [part0051.html#page_338]
managing undesirable, 89 [part0023.html#page_89]–90 [part0023.html#page_90]
OCP example, 72 [part0020.html#page_72]
in package by layer, 304 [part0049.html#page_304]–306 [part0049.html#page_306], 310 [part0049.html#page_310]–311 [part0049.html#page_311]
software destroyed by unmanaged, 256 [part0043.html#page_256]
stable. See SDP (Stable Dependencies Principle) [part0052.html#idx359]
transitive, 75 [part0020.html#page_75]
understanding component, 121 [part0027.html#page_121]
in Union Accounting archaeology project, 333 [part0051.html#page_333]–334 [part0051.html#page_334]
Dependency graph, 115 [part0027.html#page_115]–118 [part0027.html#page_118]
Dependency Injection framework, Main component, 232 [part0040.html#page_232]
Dependency inversion, 44 [part0016.html#page_44]–47 [part0016.html#page_47]
Dependency management
metrics. See ADP (Acyclic Dependencies Principle) [part0052.html#idx13]
via full-fledged architectural boundaries, 218 [part0038.html#page_218]
via polymorphism in monolithic systems, 177 [part0032.html#page_177]
video sales case study, 302 [part0048.html#page_302]
Dependency Rule
clean architecture and, 203 [part0036.html#page_203]–206 [part0036.html#page_206]
clean architecture scenario, 207 [part0036.html#page_207]–208 [part0036.html#page_208]
crossing boundaries, 206 [part0036.html#page_206]
defined, 91 [part0023.html#page_91]
dependency management, 302 [part0048.html#page_302]
designing services to follow, 247 [part0041.html#page_247]
Entities, 204 [part0036.html#page_204]
frameworks and drivers, 205 [part0036.html#page_205]
frameworks tending to violate, 293 [part0047.html#page_293]
in Hunt the Wumpus adventure game, 223 [part0039.html#page_223]
interface adapters, 205 [part0036.html#page_205]
OO approach for cross-cutting concerns, 244 [part0041.html#page_244]–245 [part0041.html#page_245]
services may follow, 240 [part0041.html#page_240]
tests following, 250 [part0042.html#page_250]
use cases, 204 [part0036.html#page_204]
which data crosses boundaries, 207 [part0036.html#page_207]
Deployment
architecture determines ease of, 150 [part0030.html#page_150]
components, 178 [part0032.html#page_178]–180 [part0032.html#page_180]
components as units of, 96 [part0025.html#page_96]
impact of architecture on, 138 [part0029.html#page_138]
tests use independent, 250 [part0042.html#page_250]
Deployment-level decoupling mode, 156 [part0030.html#page_156]–157 [part0030.html#page_157], 178 [part0032.html#page_178]–179 [part0032.html#page_179]
Design
approaches to. See Code organization [part0052.html#idx69]
architecture vs., 4 [part0011.html#page_4]
decreasing productivity/increases cost of code, 5 [part0011.html#page_5]–7 [part0011.html#page_7]
getting it right, 2 [part0010.html#page_2]
goal of good, 4 [part0011.html#page_4]–5 [part0011.html#page_5]
reducing volatility of interfaces, 88 [part0023.html#page_88]
signature of a mess, 7 [part0011.html#page_7]–8 [part0011.html#page_8]
SOLID principles of, 57 [part0018.html#page_57]–59 [part0018.html#page_59]
for testability, 251 [part0042.html#page_251]
Designing Object-Oriented C++ Applications Using the Booch Method, 369 [part0051.html#page_369]
Detail
database is. See Database is detail [part0052.html#idx114]
don’t reveal hardware, to user of HAL, 265 [part0043.html#page_265]–269 [part0043.html#page_269]
framework is, 291 [part0047.html#page_291]–295 [part0047.html#page_295]
hardware is, 263 [part0043.html#page_263]–264 [part0043.html#page_264]
separating from policy, 140 [part0029.html#page_140]–142 [part0029.html#page_142]
story of architectural success, 163 [part0031.html#page_163]–165 [part0031.html#page_165]
web is, 285 [part0046.html#page_285]–289 [part0046.html#page_289]
Developers
decreasing productivity/increasing cost of code, 5 [part0011.html#page_5]–7 [part0011.html#page_7]
Eisenhower’s matrix of importance vs. urgency, 17 [part0012.html#page_17]
foolishness of overconfidence, 9 [part0011.html#page_9]–12 [part0011.html#page_12]
preference for function vs. architecture, 15 [part0012.html#page_15]–16 [part0012.html#page_16]
scope vs. shape in determining cost of change, 15 [part0012.html#page_15]
signature of a mess, 8 [part0011.html#page_8]–9 [part0011.html#page_9]
as stakeholders, 18 [part0012.html#page_18]
Development
impact of architecture on, 137 [part0029.html#page_137]–138 [part0029.html#page_138]
independent. See Independent developability [part0052.html#idx208]
role of architecture in supporting, 149 [part0030.html#page_149]–150 [part0030.html#page_150]
role of test to support, 250 [part0042.html#page_250]
Device independence
defined, 142 [part0029.html#page_142]–143 [part0029.html#page_143]
IO device of UI as, 288 [part0046.html#page_288]–289 [part0046.html#page_289]
junk mail example, 144 [part0029.html#page_144]–145 [part0029.html#page_145]
physical addressing example, 145 [part0029.html#page_145]–146 [part0029.html#page_146]
in programming, 44 [part0016.html#page_44]
Digital revolution, and telephone companies, 352 [part0051.html#page_352]–354 [part0051.html#page_354]
Dijkstra, Edsger Wybe
applying discipline of proof to programming, 27 [part0015.html#page_27]
discovery of structured programming, 22 [part0014.html#page_22]
history of, 26 [part0015.html#page_26]
proclamation on goto statements, 28 [part0015.html#page_28]–29 [part0015.html#page_29]
on testing, 31 [part0015.html#page_31]
DIP (Dependency Inversion Principle)
breaking cycle of components, 117 [part0027.html#page_117]–118 [part0027.html#page_118]
conclusion, 91 [part0023.html#page_91]
concrete components, 91 [part0023.html#page_91]
crossing circle boundaries, 206 [part0036.html#page_206]
defined, 59 [part0018.html#page_59]
drawing boundary lines, 173 [part0031.html#page_173]
Entities without knowledge of use cases as, 193 [part0034.html#page_193]
factories, 89 [part0023.html#page_89]–90 [part0023.html#page_90]
in good software architecture, 71 [part0020.html#page_71]
not all components should be stable, 125 [part0027.html#page_125]
overview of, 87 [part0023.html#page_87]–88 [part0023.html#page_88]
stable abstractions, 88 [part0023.html#page_88]–89 [part0023.html#page_89]
Stable Abstractions Principle, 127 [part0027.html#page_127]
Directed acyclic graph. See DAGs (directed acyclic graphs) [part0052.html#idx108]
Directional control, Open-Closed Principle, 74 [part0020.html#page_74]
Disks
if there were no, 280 [part0045.html#page_280]–281 [part0045.html#page_281]
prevalence of database systems due to, 279 [part0045.html#page_279]–280 [part0045.html#page_280]
in Union Accounting archaeology project, 326 [part0051.html#page_326]–330 [part0051.html#page_330]
Dispatch code, service area computer project, 345 [part0051.html#page_345]
Display local unit/display remote unit (DLU/DRU) archaeology project, 354 [part0051.html#page_354]–356 [part0051.html#page_356]
DLU/DRU (display local unit/display remote unit), archaeology project, 354 [part0051.html#page_354]–356 [part0051.html#page_356]
Do/while/until statements, 22 [part0014.html#page_22], 27 [part0015.html#page_27]
Don’t Repeat Yourself (DRY) principle, conditional compilation directives, 272 [part0043.html#page_272]
Drawing lines. See Boundaries [part0052.html#idx37]
Drivers, Dependency Rule, 205 [part0036.html#page_205]
DRY (Don’t Repeat Yourself) principle, conditional compilation directives, 272 [part0043.html#page_272]
DSL (domain-specific data-driven language), Laser Trim archaeology project, 337 [part0051.html#page_337]
Duplication
accidental, 63 [part0019.html#page_63]–65 [part0019.html#page_65]
true vs. accidental, 154 [part0030.html#page_154]–155 [part0030.html#page_155]
Dynamic polymorphism, 177 [part0032.html#page_177]–178 [part0032.html#page_178], 206 [part0036.html#page_206]
Dynamically linked libraries, as architectural boundaries, 178 [part0032.html#page_178]–179 [part0032.html#page_179]
Dynamically typed languages
DIP and, 88 [part0023.html#page_88]
ISP and, 85 [part0022.html#page_85]
E
Editing, Laser Trim archaeology project, 336 [part0051.html#page_336]
Educational Testing Service (ETS), 370 [part0051.html#page_370]–372 [part0051.html#page_372]
Eisenhower, matrix of importance vs. urgency, 16 [part0012.html#page_16]–17 [part0012.html#page_17]
Embedded architecture. See Clean embedded architecture [part0052.html#idx63]
Encapsulation
in defining OOP, 35 [part0016.html#page_35]–37 [part0016.html#page_37]
organization vs., 316 [part0049.html#page_316]–319 [part0049.html#page_319]
overuse of public and, 316 [part0049.html#page_316]
Entities
business rules and, 190 [part0034.html#page_190]–191 [part0034.html#page_191]
clean architecture scenario, 207 [part0036.html#page_207]–208 [part0036.html#page_208]
creating testable architecture, 198 [part0035.html#page_198]
Dependency Rule for, 204 [part0036.html#page_204]
risks of frameworks, 293 [part0047.html#page_293]
use cases vs., 191 [part0034.html#page_191]–193 [part0034.html#page_193]
Enumeration, Dijkstra’s proof for sequence/selection, 28 [part0015.html#page_28]
EPROM (Erasable Programmable Read-Only Memory) chips, 4 [part0011.html#page_4]-TEL archaeology project, 341 [part0051.html#page_341]–343 [part0051.html#page_343]
ER (Electronic Receptionist)
archaeology project, 359 [part0051.html#page_359]–361 [part0051.html#page_361]
Craft Dispatch System was, 362 [part0051.html#page_362]–364 [part0051.html#page_364]
ETS (Educational Testing Service), 370 [part0051.html#page_370]–372 [part0051.html#page_372]
Europe, redesigning SAC for US and, 347 [part0051.html#page_347]–348 [part0051.html#page_348]
Event sourcing, storing transactions, 54 [part0017.html#page_54]–55 [part0017.html#page_55]
Executables
deployment of monoliths, 176 [part0032.html#page_176]–178 [part0032.html#page_178]
linking components as, 96 [part0025.html#page_96]
External agency, clean architecture independence from, 202 [part0036.html#page_202]
External definition, compilers, 100 [part0025.html#page_100]
External reference, compilers, 100 [part0025.html#page_100]
F
Facade pattern, partial boundaries, 220 [part0038.html#page_220]
Fan-in/fan-out metrics, component stability, 122 [part0027.html#page_122]–123 [part0027.html#page_123]
Feathers, Michael, 58 [part0018.html#page_58]
File systems, mitigating time delay, 279 [part0045.html#page_279]–280 [part0045.html#page_280]
Firewalls, boundary crossings via, 176 [part0032.html#page_176]
Firmware
in 4 [part0011.html#page_4]-TEL archaeology project, 343 [part0051.html#page_343]–344 [part0051.html#page_344]
definitions of, 256 [part0043.html#page_256]–257 [part0043.html#page_257]
eliminating target-hardware bottleneck, 262 [part0043.html#page_262]–263 [part0043.html#page_263]
fuzzy line between software and, 263 [part0043.html#page_263]–264 [part0043.html#page_264]
obsolete as hardware evolves, 256 [part0043.html#page_256]
stop writing so much, 257 [part0043.html#page_257]–258 [part0043.html#page_258]
FitNesse program
overview of, 163 [part0031.html#page_163]–165 [part0031.html#page_165]
partial boundary, 218 [part0038.html#page_218]–219 [part0038.html#page_219]
FLD (Field Labeled Data), Craft Dispatch System archaeology project, 363 [part0051.html#page_363]
Flow of control
crossing circle boundaries, 206 [part0036.html#page_206]
dependency management, case study, 302 [part0048.html#page_302]
dynamic polymorphism, 177 [part0032.html#page_177]–178 [part0032.html#page_178]
in Union Accounting archaeology project, 334 [part0051.html#page_334]
Fowler, Martin, 305 [part0049.html#page_305]–306 [part0049.html#page_306]
Fragile Tests Problem, 251 [part0042.html#page_251]
Frameworks
avoid basing architecture on, 197 [part0035.html#page_197]
clean architecture independent from, 202 [part0036.html#page_202]
creating testable architecture without, 198 [part0035.html#page_198]
Dependency Rule for, 205 [part0036.html#page_205]
as option to be left open, 197 [part0035.html#page_197]
as tools, not a way of life, 198 [part0035.html#page_198]
Frameworks are details
asymmetric marriage and, 292 [part0047.html#page_292]–293 [part0047.html#page_293]
conclusion, 295 [part0047.html#page_295]
framework authors, 292 [part0047.html#page_292]
frameworks you must simply marry, 295 [part0047.html#page_295]
popularity of, 292 [part0047.html#page_292]
risks, 293 [part0047.html#page_293]–294 [part0047.html#page_294]
solution, 294 [part0047.html#page_294]
Function calls, services as, 240 [part0041.html#page_240]
Functional decomposition
programming best practice, 32 [part0015.html#page_32]
in structured programming, 29 [part0015.html#page_29]
Functional pointers, OOP, 22 [part0014.html#page_22], 23 [part0014.html#page_23]
Functional programming
conclusion, 56 [part0017.html#page_56]
event sourcing, 54 [part0017.html#page_54]–55 [part0017.html#page_55]
history of, 22 [part0014.html#page_22]–23 [part0014.html#page_23]
immutability, 52 [part0017.html#page_52]
overview of, 50 [part0017.html#page_50]
segregation of mutability, 52 [part0017.html#page_52]–54 [part0017.html#page_54]
squares of integers example, 50 [part0017.html#page_50]–51 [part0017.html#page_51]
Functions
avoid overriding concrete, 89 [part0023.html#page_89]
breaking down into parts (functional decomposition), 29 [part0015.html#page_29]
one of three big concerns in architecture, 24 [part0014.html#page_24]
principle of doing one thing, 62 [part0019.html#page_62]
separating from data, 66 [part0019.html#page_66]
SRP examples, 67 [part0019.html#page_67]
G
Gateways, database, 214 [part0037.html#page_214]
GE Datanet 30 [part0015.html#page_30] computer, Union Accounting archaeology project, 326 [part0051.html#page_326]–330 [part0051.html#page_330]
Goto statements
Dijkstra replaces with iteration control structures, 27 [part0015.html#page_27]
Dijkstra’s proclamation on harmfulness of, 28 [part0015.html#page_28]–29 [part0015.html#page_29]
history of structured programming, 22 [part0014.html#page_22]
removed in structured programming, 23 [part0014.html#page_23]
Growing Object Oriented Software with Tests (Freeman & Pryce), 202 [part0036.html#page_202]
GUI (graphical user interface). See also UI (user interface) [part0052.html#idx418]
decoupling business rules from, 287 [part0046.html#page_287]–289 [part0046.html#page_289]
designing for testability, 251 [part0042.html#page_251]
developing architects registry exam, 371 [part0051.html#page_371]–372 [part0051.html#page_372]
input/output and boundary lines, 169 [part0031.html#page_169]–170 [part0031.html#page_170]
plugin architecture, 170 [part0031.html#page_170]–171 [part0031.html#page_171]
plugin argument, 172 [part0031.html#page_172]–173 [part0031.html#page_173]
separating from business rules with boundaries, 165 [part0031.html#page_165]–169 [part0031.html#page_169]
unit testing, 212 [part0037.html#page_212]
web is, 288 [part0046.html#page_288]
H
HAL (hardware abstraction layer)
avoid revealing hardware details to user of, 265 [part0043.html#page_265]–269 [part0043.html#page_269]
as boundary line between software/firmware, 264 [part0043.html#page_264]
DRY conditional compilation directives, 272 [part0043.html#page_272]
operating system is detail and, 269 [part0043.html#page_269]–271 [part0043.html#page_271]
Hardware
eliminating target-hardware bottleneck with layers, 262 [part0043.html#page_262]–263 [part0043.html#page_263]
firmware becomes obsolete through evolution of, 256 [part0043.html#page_256]
in SAC archaeology project, 346 [part0051.html#page_346]–347 [part0051.html#page_347]
Header files, programming to interfaces with, 272 [part0043.html#page_272]
Hexagonal Architecture (Ports and Adapters), 202 [part0036.html#page_202]
High-level policy
decoupling from lower level input/output policies, 185 [part0033.html#page_185]–186 [part0033.html#page_186]
separating details from, 140 [part0029.html#page_140]–142 [part0029.html#page_142]
splitting data streams, 227 [part0039.html#page_227]–228 [part0039.html#page_228]
where to place, 126 [part0027.html#page_126]
Human resources, goal of architect to minimize, 160 [part0031.html#page_160]
Humble Object pattern
data mappers, 214 [part0037.html#page_214]–215 [part0037.html#page_215]
database getaways, 214 [part0037.html#page_214]
Presenters and Views, 212 [part0037.html#page_212]–213 [part0037.html#page_213]
Presenters as form of, 212 [part0037.html#page_212]
testing and architecture, 213 [part0037.html#page_213]
understanding, 212 [part0037.html#page_212]
Hunt the Wumpus game
layers and boundaries. See Layers and boundaries [part0052.html#idx231]
Main component from, 232 [part0040.html#page_232]–237 [part0040.html#page_237]
I
IBM System/7, aluminum die-cast archaeology project, 338 [part0051.html#page_338]–339 [part0051.html#page_339]
If/then/else statements, 22 [part0014.html#page_22], 27 [part0015.html#page_27]
Immutability, 52 [part0017.html#page_52]–54 [part0017.html#page_54]
Implementation strategy. See Code organization [part0052.html#idx69]
Importance, urgency vs. Eisenhower’s matrix of, 16 [part0012.html#page_16]–17 [part0012.html#page_17]
Incoming dependencies, stability metrics, 122 [part0027.html#page_122]–123 [part0027.html#page_123]
Independence
conclusion, 158 [part0030.html#page_158]
decoupling layers, 151 [part0030.html#page_151]–152 [part0030.html#page_152]
decoupling mode, 153 [part0030.html#page_153]
decoupling use cases, 152 [part0030.html#page_152]
deployment, 150 [part0030.html#page_150]
development, 149 [part0030.html#page_149]–150 [part0030.html#page_150]
duplication, 154 [part0030.html#page_154]–155 [part0030.html#page_155]
independent deployability, 154 [part0030.html#page_154]
independent developability, 153 [part0030.html#page_153]–154 [part0030.html#page_154]
leaving options open, 150 [part0030.html#page_150]–151 [part0030.html#page_151]
operation, 149 [part0030.html#page_149]
overview of, 147 [part0030.html#page_147]–148 [part0030.html#page_148]
types of decoupling modes, 155 [part0030.html#page_155]–158 [part0030.html#page_158]
use cases, 148 [part0030.html#page_148]
Independent components
calculating stability metrics, 123 [part0027.html#page_123]
understanding, 121 [part0027.html#page_121]
Independent deployability
in 4 [part0011.html#page_4]-TEL archaeology project, 344 [part0051.html#page_344]
as fallacy of services, 241 [part0041.html#page_241]
kitty problem example, 242 [part0041.html#page_242]–243 [part0041.html#page_243]
in OO approach for cross-cutting concerns, 244 [part0041.html#page_244]–245 [part0041.html#page_245]
overview of, 154 [part0030.html#page_154]
Independent developability
as fallacy of services, 241 [part0041.html#page_241]
kitty problem example, 242 [part0041.html#page_242]–243 [part0041.html#page_243]
in OO approach for cross-cutting concerns, 244 [part0041.html#page_244]–245 [part0041.html#page_245]
overview of, 153 [part0030.html#page_153]–154 [part0030.html#page_154]
of UI and database, 47 [part0016.html#page_47]
Induction, Dijkstra’s proof related to iteration, 28 [part0015.html#page_28]
Information hiding, Open-Closed Principle, 74 [part0020.html#page_74]–75 [part0020.html#page_75]
Inheritance relationships
crossing circle boundaries, 206 [part0036.html#page_206]
defining OOP, 37 [part0016.html#page_37]–40 [part0016.html#page_40]
dependency inversion, 46 [part0016.html#page_46]
dependency management, 302 [part0048.html#page_302]
guiding use of, 78 [part0021.html#page_78]
Input/output
business rules for use cases, 193 [part0034.html#page_193]–194 [part0034.html#page_194]
decoupling higher-level policy from lower level, 185 [part0033.html#page_185]–187 [part0033.html#page_187]
policy level defined as distance from, 184 [part0033.html#page_184]
separating components with boundary lines, 169 [part0031.html#page_169]–170 [part0031.html#page_170]
Integers, functional programming example, 50 [part0017.html#page_50]–51 [part0017.html#page_51]
Integration, weekly build issues, 112 [part0027.html#page_112]–113 [part0027.html#page_113]
Interface adapters, Dependency Rule for, 205 [part0036.html#page_205]
Interface Segregation Principle. See ISP (Interface Segregation Principle) [part0052.html#idx219]
IO device
UNIX functions, 41 [part0016.html#page_41]–44 [part0016.html#page_44]
web is, 288 [part0046.html#page_288]–289 [part0046.html#page_289]
Isolation, test, 250 [part0042.html#page_250]–251 [part0042.html#page_251]
ISP (Interface Segregation Principle)
architecture and, 86 [part0022.html#page_86]
Common Reuse Principle compared with, 108 [part0026.html#page_108]
conclusion, 86 [part0022.html#page_86]
defined, 59 [part0018.html#page_59]
language type and, 85 [part0022.html#page_85]
overview of, 84 [part0022.html#page_84]–85 [part0022.html#page_85]
Iteration, 27 [part0015.html#page_27]–28 [part0015.html#page_28]
J
Jacobson, Ivar, 196 [part0035.html#page_196], 202 [part0036.html#page_202]
Jar files
component architecture, 301 [part0048.html#page_301]
components as, 96 [part0025.html#page_96]
creating partial boundary, 219 [part0038.html#page_219]
defining function of components, 313 [part0049.html#page_313]
designing component-based services, 245 [part0041.html#page_245]–246 [part0041.html#page_246]
Download and Go rule for, 163 [part0031.html#page_163]
in source-level decoupling mode, 176 [part0032.html#page_176]
Java
abstract components in, 125 [part0027.html#page_125]
code organization approaches in. See Code organization [part0052.html#idx69]
components as jar files in, 96 [part0025.html#page_96]
DIP and, 87 [part0023.html#page_87]
import statements for dependencies, 184 [part0033.html#page_184]
ISP example, 84 [part0022.html#page_84]–85 [part0022.html#page_85]
marrying standard library framework in, 293 [part0047.html#page_293]
module frameworks in, 319 [part0049.html#page_319]
package by layer in, 304 [part0049.html#page_304]–306 [part0049.html#page_306]
squares of integers example in, 50 [part0017.html#page_50]–51 [part0017.html#page_51]
weakening encapsulation, 36 [part0016.html#page_36]–37 [part0016.html#page_37]
Jitters, breaking cycle of components, 118 [part0027.html#page_118]
Junk mail example, 144 [part0029.html#page_144]–145 [part0029.html#page_145]
K
Kitty problem example, 242 [part0041.html#page_242]–245 [part0041.html#page_245]
L
Languages
clean architecture and, 223 [part0039.html#page_223]–226 [part0039.html#page_226]
Hunt the Wumpus adventure game, 222 [part0039.html#page_222]–223 [part0039.html#page_223]
Laser Trim, archaeology project
4-TEL project, 339 [part0051.html#page_339]
overview of, 334 [part0051.html#page_334]–338 [part0051.html#page_338]
Layered architecture
package by layer code organization, 304 [part0049.html#page_304]–306 [part0049.html#page_306]
relaxed, 311 [part0049.html#page_311]–312 [part0049.html#page_312]
why it is considered bad, 310 [part0049.html#page_310]–311 [part0049.html#page_311]
Layers
approach to code organization, 304 [part0049.html#page_304]–306 [part0049.html#page_306]
clean architecture using, 202 [part0036.html#page_202]–203 [part0036.html#page_203]
decoupling, 151 [part0030.html#page_151]–152 [part0030.html#page_152]
duplication of, 155 [part0030.html#page_155]
eliminating target-hardware bottleneck, 262 [part0043.html#page_262]–263 [part0043.html#page_263]
independent developability, 154 [part0030.html#page_154]
Layers and boundaries
clean architecture, 223 [part0039.html#page_223]–226 [part0039.html#page_226]
conclusion, 228 [part0039.html#page_228]
crossing streams, 226 [part0039.html#page_226]
Hunt the Wumpus adventure game, 222 [part0039.html#page_222]–223 [part0039.html#page_223]
overview of, 221 [part0039.html#page_221]–222 [part0039.html#page_222]
splitting streams, 227 [part0039.html#page_227]–228 [part0039.html#page_228]
Leiningen tool, module management, 104 [part0026.html#page_104]
Level
hierarchy of protection and, 74 [part0020.html#page_74]
policy and, 184 [part0033.html#page_184]–187 [part0033.html#page_187]
Libraries
location of source code, 97 [part0025.html#page_97]–98 [part0025.html#page_98]
relocatable binaries, 99 [part0025.html#page_99]–100 [part0025.html#page_100]
Life cycle, architecture supports system, 137 [part0029.html#page_137]
Linkers, separating from loaders, 100 [part0025.html#page_100]–102 [part0025.html#page_102]
Liskov, Barbara, 78 [part0021.html#page_78]
Liskov Substitution Principle (LSP). See LSP (Liskov Substitution Principle) [part0052.html#idx243]
LISP langauge, functional programming, 23 [part0014.html#page_23]
Lisp language, squares of integers example, 50 [part0017.html#page_50]–51 [part0017.html#page_51]
Loaders
linking, 100 [part0025.html#page_100]–102 [part0025.html#page_102]
relocatable binaries, 99 [part0025.html#page_99]–100 [part0025.html#page_100]
Local process boundaries, 179 [part0032.html#page_179]–180 [part0032.html#page_180]
LSP (Liskov Substitution Principle)
architecture and, 80 [part0021.html#page_80]
conclusion, 82 [part0021.html#page_82]
defined, 59 [part0018.html#page_59]
guiding use of inheritance, 78 [part0021.html#page_78]
overview of, 78 [part0021.html#page_78]
square/rectangle example problem, 79 [part0021.html#page_79]
violation of, 80 [part0021.html#page_80]–82 [part0021.html#page_82]
M
M365 computer
4-TEL archaeology project, 340 [part0051.html#page_340]–341 [part0051.html#page_341]
Laser Trim archaeology project, 335 [part0051.html#page_335]–338 [part0051.html#page_338]
SAC archaeology project, 345 [part0051.html#page_345]–347 [part0051.html#page_347]
Mailboxes, local processes communicate via, 180 [part0032.html#page_180]
Main component
conclusion, 237 [part0040.html#page_237]
as concrete component, 91 [part0023.html#page_91]
defined, 232 [part0040.html#page_232]
object-oriented programming, 40 [part0016.html#page_40]
polymorphism, 45 [part0016.html#page_45]
small impact of releasing, 115 [part0027.html#page_115]
as ultimate detail, 232 [part0040.html#page_232]–237 [part0040.html#page_237]
Main Sequence
avoiding Zones of Exclusion via, 130 [part0027.html#page_130]
defining relationship between abstraction/stability, 127 [part0027.html#page_127]–128 [part0027.html#page_128]
measuring distance from, 130 [part0027.html#page_130]–132 [part0027.html#page_132]
Zone of Pain, 129 [part0027.html#page_129]
Zone of Uselessness, 129 [part0027.html#page_129]–130 [part0027.html#page_130]
Maintenance, impact of architecture on, 139 [part0029.html#page_139]–140 [part0029.html#page_140]
Marketing campaigns, database vendor, 283 [part0045.html#page_283]
Master Operating Program (MOP), Laser Trim archaeology project, 336 [part0051.html#page_336]
Mathematics
contrasting science with, 30 [part0015.html#page_30]
discipline of proof, 27 [part0015.html#page_27]–28 [part0015.html#page_28]
Maven tool, module management, 104 [part0026.html#page_104]
McCarthy, John, 23 [part0014.html#page_23]
Memory
early layout of, 98 [part0025.html#page_98]–99 [part0025.html#page_99]
local processes and, 179 [part0032.html#page_179]
RAM. See RAM [part0052.html#idx329]
Merges, SRP examples, 65 [part0019.html#page_65]
Message queues, local processes communicate via, 180 [part0032.html#page_180]
Metrics
abstraction, 127 [part0027.html#page_127]
distance from Main Sequence, 130 [part0027.html#page_130]–132 [part0027.html#page_132]
Meyer, Bertrand, 70 [part0020.html#page_70]
Micro-service architecture
in Craft Dispatch System archaeology project, 362 [part0051.html#page_362]–363 [part0051.html#page_363]
decoupling mode, 153 [part0030.html#page_153]
deployment strategy, 138 [part0029.html#page_138]
popularity of, 239 [part0041.html#page_239]
Modems, SAC archaeology project, 346 [part0051.html#page_346]–347 [part0051.html#page_347]
Modules
Common Reuse Principle, 107 [part0026.html#page_107]–108 [part0026.html#page_108]
defined, 62 [part0019.html#page_62]
management tools, 104 [part0026.html#page_104]
public types vs. published types, 319 [part0049.html#page_319]
Reuse/Release Equivalence Principle, 105 [part0026.html#page_105]
Monoliths
building scalable systems, 241 [part0041.html#page_241]
deployment-level components vs., 179 [part0032.html#page_179]
deployment of, 176 [part0032.html#page_176]–178 [part0032.html#page_178]
function calls, 240 [part0041.html#page_240]
local processes as statically linked, 180 [part0032.html#page_180]
threads, 179 [part0032.html#page_179]
Moore’s Law, 101 [part0025.html#page_101]
MOP (Master Operating Program), Laser Trim archaeology project, 336 [part0051.html#page_336]
Morning after syndrome
eliminating dependency cycles to solve, 113 [part0027.html#page_113]–115 [part0027.html#page_115]
managing dependencies to prevent, 118 [part0027.html#page_118]
overview of, 112 [part0027.html#page_112]
weekly build issues, 112 [part0027.html#page_112]–113 [part0027.html#page_113]
MPS (multiprocessing system), SAC archaeology project, 345 [part0051.html#page_345]–346 [part0051.html#page_346]
Mutability, 52 [part0017.html#page_52]–54 [part0017.html#page_54]
Mutable variables, 51 [part0017.html#page_51], 54 [part0017.html#page_54]–55 [part0017.html#page_55]
N
National Council of Architects Registry Board (NCARB), 370 [part0051.html#page_370]–372 [part0051.html#page_372]
.NET, components as DLLs, 96 [part0025.html#page_96]
NetNews, presence of author on, 367 [part0051.html#page_367]–369 [part0051.html#page_369]
Newkirk, Jim, 371 [part0051.html#page_371]–372 [part0051.html#page_372]
Nygaard, Kristen, 22 [part0014.html#page_22]
O
Object-oriented databases, ROSE product, 368 [part0051.html#page_368]–370 [part0051.html#page_370]
Object Oriented Design with Applications (Booch), 366 [part0051.html#page_366], 368 [part0051.html#page_368]
Object-oriented programming
conclusion, 47 [part0016.html#page_47]
for cross-cutting concerns, 244 [part0041.html#page_244]–245 [part0041.html#page_245]
dependency inversion, 44 [part0016.html#page_44]–47 [part0016.html#page_47]
deployment of monoliths, 177 [part0032.html#page_177]
encapsulation, 35 [part0016.html#page_35]–37 [part0016.html#page_37]
history of, 22 [part0014.html#page_22]
inheritance, 37 [part0016.html#page_37]–40 [part0016.html#page_40]
overview of, 34 [part0016.html#page_34]–35 [part0016.html#page_35]
polymorphism, 40 [part0016.html#page_40]–43 [part0016.html#page_43]
power of polymorphism, 43 [part0016.html#page_43]–44 [part0016.html#page_44]
Object Oriented Software Engineering (Jacobson), 196 [part0035.html#page_196], 202 [part0036.html#page_202]
Object relational mappers (ORMs), 214 [part0037.html#page_214]–215 [part0037.html#page_215]
Objects, invented in 4 [part0011.html#page_4]-TEL archaeology project, 344 [part0051.html#page_344]
OCP (Open-Closed Principle)
birth of, 142 [part0029.html#page_142]
Common Closure Principle compared with, 106 [part0026.html#page_106]
conclusion, 75 [part0020.html#page_75]
in Craft Dispatch System archaeology project, 363 [part0051.html#page_363]
defined, 59 [part0018.html#page_59]
dependency management, 302 [part0048.html#page_302]
designing component-based services, 246 [part0041.html#page_246]
directional control, 74 [part0020.html#page_74]
information hiding, 74 [part0020.html#page_74]–75 [part0020.html#page_75]
overview of, 70 [part0020.html#page_70]
thought experiment, 71 [part0020.html#page_71]–74 [part0020.html#page_74]
OMC (Outboard Marine Corporation), aluminum die-cast archaeology project, 338 [part0051.html#page_338]–339 [part0051.html#page_339]
One-dimensional boundaries, 219 [part0038.html#page_219]
Open-Closed Principle. See OCP (Open-Closed Principle) [part0052.html#idx280]
Operating system abstraction layer (OSAL), clean embedded architecture, 270 [part0043.html#page_270]–271 [part0043.html#page_271]
Operating system (OS), is detail, 269 [part0043.html#page_269]–271 [part0043.html#page_271]
Operations
architecture supports system, 138 [part0029.html#page_138]–139 [part0029.html#page_139], 149 [part0030.html#page_149]
decoupling use cases for, 153 [part0030.html#page_153]
use cases affected by changes in, 204 [part0036.html#page_204]
Options, keeping open
good architecture makes system easy to change, 150 [part0030.html#page_150]–151 [part0030.html#page_151]
operational architecture, 149 [part0030.html#page_149]
purpose of architecture, 140 [part0029.html#page_140]–142 [part0029.html#page_142], 197 [part0035.html#page_197]
via decoupling mode, 153 [part0030.html#page_153]
Organization vs. encapsulation, 316 [part0049.html#page_316]–319 [part0049.html#page_319]
ORMs (object relational mappers), 214 [part0037.html#page_214]–215 [part0037.html#page_215]
OS (operating system), is detail, 269 [part0043.html#page_269]–271 [part0043.html#page_271]
OSAL (operating system abstraction layer), clean embedded architecture, 270 [part0043.html#page_270]–271 [part0043.html#page_271]
Oscillations, web as one of many, 285 [part0046.html#page_285]–289 [part0046.html#page_289]
Outgoing dependencies, stability metrics, 122 [part0027.html#page_122]–123 [part0027.html#page_123]
Overconfidence, foolishness of, 9 [part0011.html#page_9]–12 [part0011.html#page_12]
P
Package by component, 310 [part0049.html#page_310]–315 [part0049.html#page_315], 318 [part0049.html#page_318]
Package by feature, 306 [part0049.html#page_306]–307 [part0049.html#page_307], 317 [part0049.html#page_317]
Package by layer
access modifiers, 317 [part0049.html#page_317]–318 [part0049.html#page_318]
horizontal layering of code, 304 [part0049.html#page_304]–306 [part0049.html#page_306]
why it is considered bad, 310 [part0049.html#page_310]–311 [part0049.html#page_311]
Packages, organization vs. encapsulation, 316 [part0049.html#page_316]–319 [part0049.html#page_319]
Page-Jones, Meilir, 29 [part0015.html#page_29]
Partial boundaries
conclusion, 220 [part0038.html#page_220]
facades, 220 [part0038.html#page_220]
one-dimensional boundaries, 219 [part0038.html#page_219]
reasons to implement, 217 [part0038.html#page_217]–218 [part0038.html#page_218]
skip last step, 218 [part0038.html#page_218]–219 [part0038.html#page_219]
Patches, in 4 [part0011.html#page_4]-TEL archaeology project, 344 [part0051.html#page_344]
PCCU, archaeology project, 352 [part0051.html#page_352]–354 [part0051.html#page_354]
PDP-11/60 computer, 349 [part0051.html#page_349]–351 [part0051.html#page_351]
Performance, as low-level concern, 281 [part0045.html#page_281]
Périphérique anti-pattern of ports and adapters, 320 [part0049.html#page_320]–321 [part0049.html#page_321]
Physical addressing example, 145 [part0029.html#page_145]–146 [part0029.html#page_146]
Plugin architecture
in 4 [part0011.html#page_4]-TEL archaeology project, 344 [part0051.html#page_344]
for device independence, 44 [part0016.html#page_44]
drawing boundaries for axis of change, 173 [part0031.html#page_173]
of lower-level components into higher-level components, 187 [part0033.html#page_187]
Main component as, 237 [part0040.html#page_237]
start with presumption of, 170 [part0031.html#page_170]–171 [part0031.html#page_171]
Pointers
in creating polymorphic behavior, 43 [part0016.html#page_43]
functional, 22 [part0014.html#page_22]–23 [part0014.html#page_23]
Policy
in clean architecture, 203 [part0036.html#page_203]
high-level. See High-level policy [part0052.html#idx195]
overview of, 183 [part0033.html#page_183]–184 [part0033.html#page_184]
software systems as statements of, 183 [part0033.html#page_183]
splitting data streams, 227 [part0039.html#page_227]–228 [part0039.html#page_228]
Polymorphic dispatch, 4 [part0011.html#page_4]-TEL archaeology project, 344 [part0051.html#page_344]
Polymorphism
crossing circle boundaries with dynamic, 206 [part0036.html#page_206]
dependency inversion, 44 [part0016.html#page_44]–47 [part0016.html#page_47]
flow of control in dynamic, 177 [part0032.html#page_177]–178 [part0032.html#page_178]
in object-oriented programming, 22 [part0014.html#page_22], 40 [part0016.html#page_40]–43 [part0016.html#page_43]
power of, 43 [part0016.html#page_43]–44 [part0016.html#page_44]
Ports and adapters
access modifiers, 318 [part0049.html#page_318]
approach to code organization, 308 [part0049.html#page_308]–310 [part0049.html#page_310]
decouple dependencies with source code trees, 319 [part0049.html#page_319]–320 [part0049.html#page_320]
Périphérique anti-pattern of, 320 [part0049.html#page_320]–321 [part0049.html#page_321]
Positional stability, component, 122 [part0027.html#page_122]–123 [part0027.html#page_123]
Premature decisions, coupling to, 160 [part0031.html#page_160]–163 [part0031.html#page_163]
“Presentation Domain Data Layering” (Fowler), 305 [part0049.html#page_305]–306 [part0049.html#page_306]
Presenters
in clean architecture, 203 [part0036.html#page_203], 205 [part0036.html#page_205]
clean architecture scenario, 207 [part0036.html#page_207]–208 [part0036.html#page_208]
component architecture, 301 [part0048.html#page_301]
crossing circle boundaries, 206 [part0036.html#page_206]
Presenters and humble objects
conclusion, 215 [part0037.html#page_215]
data mappers, 214 [part0037.html#page_214]–215 [part0037.html#page_215]
database getaways, 214 [part0037.html#page_214]
Humble Object pattern, 212 [part0037.html#page_212]
overview of, 211 [part0037.html#page_211]–212 [part0037.html#page_212]
Presenters and Views, 212 [part0037.html#page_212]–213 [part0037.html#page_213]
service listeners, 215 [part0037.html#page_215]
testing and architecture, 213 [part0037.html#page_213]
Processes, partitioning into classes/separating classes, 71 [part0020.html#page_71]–72 [part0020.html#page_72]
Processor
is detail, 265 [part0043.html#page_265]–269 [part0043.html#page_269]
mutability and, 52 [part0017.html#page_52]
Product, video sales case study, 298 [part0048.html#page_298]
Productivity
decreasing, increasing cost of code, 5 [part0011.html#page_5]–7 [part0011.html#page_7]
signature of a mess, 8 [part0011.html#page_8]–9 [part0011.html#page_9]
Programming languages
abstract components in, 125 [part0027.html#page_125]–126 [part0027.html#page_126]
components, 96 [part0025.html#page_96]
dynamically typed, 88 [part0023.html#page_88]
ISP and, 85 [part0022.html#page_85]
statically typed, 87 [part0023.html#page_87]
variables in functional languages, 51 [part0017.html#page_51]
Programming paradigms
functional programming. See Functional programming [part0052.html#idx184]
history of, 19 [part0013.html#page_19]–20 [part0013.html#page_20]
object-oriented programming. See Object-oriented programming [part0052.html#idx276]
overview of, 21 [part0014.html#page_21]–24 [part0014.html#page_24]
structured programming. See Structured programming [part0052.html#idx400]
Proof
discipline of, 27 [part0015.html#page_27]–28 [part0015.html#page_28]
structured programming lacking, 30 [part0015.html#page_30]–31 [part0015.html#page_31]
Proxies, using with frameworks, 293 [part0047.html#page_293]
Public types
misuse of, 315 [part0049.html#page_315]–316 [part0049.html#page_316]
vs. types that are published in modules, 319 [part0049.html#page_319]
Python
DIP and, 88 [part0023.html#page_88]
ISP and, 85 [part0022.html#page_85]
R
Race conditions
due to mutable variables, 52 [part0017.html#page_52]
protecting against concurrent updates and, 53 [part0017.html#page_53]
RAM
4-TEL archaeology project, 341 [part0051.html#page_341], 343 [part0051.html#page_343]–344 [part0051.html#page_344]
replacing disks, 280 [part0045.html#page_280]–281 [part0045.html#page_281]
Rational (company), 367 [part0051.html#page_367], 368 [part0051.html#page_368]
RDBMS (relational database management systems), 279 [part0045.html#page_279]–283 [part0045.html#page_283]
Real-time operating system (RTOS) is detail, 269 [part0043.html#page_269]–271 [part0043.html#page_271]
Relational database management systems (RDBMS), 279 [part0045.html#page_279]–283 [part0045.html#page_283]
Relational databases, 278 [part0045.html#page_278], 281 [part0045.html#page_281]–283 [part0045.html#page_283]
Relaxed layered architecture, 311 [part0049.html#page_311]–312 [part0049.html#page_312]
Releases
effect of cycle in component dependency graph, 115 [part0027.html#page_115]–117 [part0027.html#page_117]
eliminating dependency cycles, 113 [part0027.html#page_113]–115 [part0027.html#page_115]
numbering new component, 113 [part0027.html#page_113]
Reuse/Release Equivalence Principle for new, 104 [part0026.html#page_104]–105 [part0026.html#page_105]
Remote terminals, DLU/DRU archaeology project, 354 [part0051.html#page_354]–356 [part0051.html#page_356]
REP (Reuse/Release Equivalence Principle), 104 [part0026.html#page_104]–105 [part0026.html#page_105], 108 [part0026.html#page_108]–110 [part0026.html#page_110]
Request models, business rules, 193 [part0034.html#page_193]–194 [part0034.html#page_194]
ReSharper, plugin argument, 172 [part0031.html#page_172]–173 [part0031.html#page_173]
Response models, business rules, 193 [part0034.html#page_193]–194 [part0034.html#page_194]
REST, leave options open in development, 141 [part0029.html#page_141]
Reusability. See CRP (Common Reuse Principle) [part0052.html#idx104]
Reuse/Release Equivalence Principle (REP), 104 [part0026.html#page_104]–105 [part0026.html#page_105], 108 [part0026.html#page_108]–110 [part0026.html#page_110]
Risks
architecture should mitigate costs of, 139 [part0029.html#page_139]–140 [part0029.html#page_140]
of frameworks, 293 [part0047.html#page_293]–294 [part0047.html#page_294]
ROM boards, 4 [part0011.html#page_4]-TEL archaeology project, 341 [part0051.html#page_341]
ROSE product, archaeology project, 368 [part0051.html#page_368]–370 [part0051.html#page_370]
RTOS (real-time operating system) is detail, 269 [part0043.html#page_269]–271 [part0043.html#page_271]
Ruby
components as gem files, 96 [part0025.html#page_96]
DIP and, 88 [part0023.html#page_88]
ISP and, 85 [part0022.html#page_85]
RVM tool, module management, 104 [part0026.html#page_104]
S
SAC (service area computer), archaeology project
4-TEL using, 340 [part0051.html#page_340]–341 [part0051.html#page_341]
architecture, 345 [part0051.html#page_345]–347 [part0051.html#page_347]
conclusion, 349 [part0051.html#page_349]
dispatch determination, 345 [part0051.html#page_345]
DLU/DRU archaeology project, 354 [part0051.html#page_354]–356 [part0051.html#page_356]
Europe, 348 [part0051.html#page_348]–349 [part0051.html#page_349]
grand redesign, 347 [part0051.html#page_347]–348 [part0051.html#page_348]
overview of, 344 [part0051.html#page_344]
SAP (Stable Abstractions Principle)
avoiding zones of exclusion, 130 [part0027.html#page_130]
distance from main sequence, 130 [part0027.html#page_130]–132 [part0027.html#page_132]
drawing boundary lines, 173 [part0031.html#page_173]
introduction to, 126 [part0027.html#page_126]–127 [part0027.html#page_127]
main sequence, 127 [part0027.html#page_127]–130 [part0027.html#page_130]
measuring abstraction, 127 [part0027.html#page_127]
where to put high-level policy, 126 [part0027.html#page_126]
SC (service center), 4 [part0011.html#page_4]-TEL archaeology project, 339 [part0051.html#page_339]–340 [part0051.html#page_340]
Scalability
kitty problem and services, 242 [part0041.html#page_242]–243 [part0041.html#page_243]
services not only option for building, 241 [part0041.html#page_241]
Schmidt, Doug, 256 [part0043.html#page_256]–258 [part0043.html#page_258]
Scientific methods, proving statements false, 30 [part0015.html#page_30]–31 [part0015.html#page_31]
Scope, of changing architecture, 15 [part0012.html#page_15]
Screaming architecture. See Architecture, screaming [part0052.html#idx22]
SDP (Stable Dependencies Principle)
abstract components, 125 [part0027.html#page_125]–126 [part0027.html#page_126]
not all components should be, 124 [part0027.html#page_124]–125 [part0027.html#page_125]
not all components should be stable, 123 [part0027.html#page_123]–125 [part0027.html#page_125]
overview of, 120 [part0027.html#page_120]
stability, 120 [part0027.html#page_120]–121 [part0027.html#page_121]
stability metrics, 122 [part0027.html#page_122]–123 [part0027.html#page_123]
Stable Abstractions Principle, 127 [part0027.html#page_127]
Security, testing API, 253 [part0042.html#page_253]
Selection, as program control structure, 27 [part0015.html#page_27]–28 [part0015.html#page_28]
Separation of components, as big concern in architecture, 24 [part0014.html#page_24]
Sequence, as program control structure, 27 [part0015.html#page_27]–28 [part0015.html#page_28]
Serial communication bus, SAC archaeology project, 347 [part0051.html#page_347]
Service area computer. See SAC (service area computer), archaeology project [part0052.html#idx351]
Service center (SC), 4 [part0011.html#page_4]-TEL archaeology project, 339 [part0051.html#page_339]–340 [part0051.html#page_340]
Service-level decoupling mode, 153 [part0030.html#page_153], 156 [part0030.html#page_156]–157 [part0030.html#page_157]
Services
component-based, 245 [part0041.html#page_245]–246 [part0041.html#page_246]
conclusion, 247 [part0041.html#page_247]
cross-cutting concerns, 246 [part0041.html#page_246]–247 [part0041.html#page_247]
decoupling fallacy, 240 [part0041.html#page_240]–241 [part0041.html#page_241]
as function calls vs. architecture, 240 [part0041.html#page_240]
Humble Object boundaries for, 214 [part0037.html#page_214]–215 [part0037.html#page_215]
independent development/deployment fallacy, 241 [part0041.html#page_241]
kitty problem, 242 [part0041.html#page_242]–243 [part0041.html#page_243]
objects to the rescue, 244 [part0041.html#page_244]–245 [part0041.html#page_245]
overview of, 239 [part0041.html#page_239]
as strongest boundary, 180 [part0032.html#page_180]–181 [part0032.html#page_181]
Set program interrupt (SPI) instruction, aluminum die-cast archaeology project, 339 [part0051.html#page_339]
Shape, of change, 15 [part0012.html#page_15]
Single Responsibility Principle. See SRP (Single Responsibility Principle) [part0052.html#idx387]
SOA (service-oriented architecture)
decoupling mode, 153 [part0030.html#page_153]
in Electronic Receptionist archaeology project, 360 [part0051.html#page_360]–361 [part0051.html#page_361]
reasons for popularity of, 239 [part0041.html#page_239]
Sockets, local processes communicate via, 180 [part0032.html#page_180]
Software
clean embedded architecture isolates OS from, 270 [part0043.html#page_270]
components. See Components [part0052.html#idx84]
eliminating target-hardware bottleneck with layers, 262 [part0043.html#page_262]–263 [part0043.html#page_263]
fuzzy line between firmware and, 263 [part0043.html#page_263]–264 [part0043.html#page_264]
getting it right, 1 [part0010.html#page_1]–2 [part0010.html#page_2]
SOLID principles, 58 [part0018.html#page_58]
value of architecture vs. behavior, 14 [part0012.html#page_14]–18 [part0012.html#page_18]
Software development
fighting for architecture over function, 18 [part0012.html#page_18]
like a science, 31 [part0015.html#page_31]
Software reuse
Common Reuse Principle, 107 [part0026.html#page_107]–108 [part0026.html#page_108]
reusable components and, 104 [part0026.html#page_104]
Reuse/Release Equivalence Principle, 104 [part0026.html#page_104]–105 [part0026.html#page_105]
SOLID principles
Dependency Inversion Principle. See DIP (Dependency Inversion Principle) [part0052.html#idx135]
designing component-based services using, 245 [part0041.html#page_245]–246 [part0041.html#page_246]
history of, 57 [part0018.html#page_57]–59 [part0018.html#page_59]
Interface Segregation Principle. See ISP (Interface Segregation Principle) [part0052.html#idx219]
Liskov Substitution Principle. See LSP (Liskov Substitution Principle) [part0052.html#idx243]
OO approach for cross-cutting concerns, 244 [part0041.html#page_244]–245 [part0041.html#page_245]
Open-Closed Principle. See OCP (Open-Closed Principle) [part0052.html#idx280]
Single Responsibility Principle. See SRP (Single Responsibility Principle) [part0052.html#idx387]
Source code, compiling, 97 [part0025.html#page_97]–98 [part0025.html#page_98]
Source code dependencies
creating boundary crossing via, 176 [part0032.html#page_176]
crossing circle boundaries, 206 [part0036.html#page_206]
decoupling, 184 [part0033.html#page_184]–185 [part0033.html#page_185], 319 [part0049.html#page_319]
dependency inversion, 44 [part0016.html#page_44]–47 [part0016.html#page_47]
local processes as, 180 [part0032.html#page_180]
OCP example, 72 [part0020.html#page_72]
referring only to abstractions, 87 [part0023.html#page_87]–88 [part0023.html#page_88]
UI components reuse game rules via, 222 [part0039.html#page_222]–223 [part0039.html#page_223]
Source code trees, decoupling dependencies, 319 [part0049.html#page_319]–321 [part0049.html#page_321]
Source-level decoupling mode, 155 [part0030.html#page_155]–157 [part0030.html#page_157], 176 [part0032.html#page_176]–178 [part0032.html#page_178]
Spelunking, architecture mitigates costs of, 139 [part0029.html#page_139]–140 [part0029.html#page_140]
SPI (set program interrupt) instruction, aluminum die-cast archaeology project, 339 [part0051.html#page_339]
Splitting data streams, 227 [part0039.html#page_227]–228 [part0039.html#page_228]
Square/rectangle problem, LSP, 79 [part0021.html#page_79]
Squares of integers, functional programming, 50 [part0017.html#page_50]–51 [part0017.html#page_51]
SRP (Single Responsibility Principle)
accidental duplication example, 63 [part0019.html#page_63]–65 [part0019.html#page_65]
Common Closure Principle vs., 106 [part0026.html#page_106]–107 [part0026.html#page_107]
conclusion, 66 [part0019.html#page_66]–67 [part0019.html#page_67]
decoupling layers, 152 [part0030.html#page_152]
defined, 59 [part0018.html#page_59]
dependency management, 302 [part0048.html#page_302]
in good software architecture, 71 [part0020.html#page_71]
grouping policies into components, 186 [part0033.html#page_186]–187 [part0033.html#page_187]
keeping changes localized, 118 [part0027.html#page_118]
merges, 65 [part0019.html#page_65]
overview of, 61 [part0019.html#page_61]–63 [part0019.html#page_63]
solutions, 66 [part0019.html#page_66]–67 [part0019.html#page_67]
use case analysis, 299 [part0048.html#page_299]
where to draw boundaries, 172 [part0031.html#page_172]–173 [part0031.html#page_173]
Stability, component
measuring, 122 [part0027.html#page_122]–123 [part0027.html#page_123]
relationship between abstraction and, 127 [part0027.html#page_127]–130 [part0027.html#page_130]
SAP. See SAP (Stable Abstractions Principle) [part0052.html#idx352]
understanding, 120 [part0027.html#page_120]–121 [part0027.html#page_121]
Stable Abstractions Principle. See SAP (Stable Abstractions Principle) [part0052.html#idx352]
Stable components
abstract components as, 125 [part0027.html#page_125]–126 [part0027.html#page_126]
as harmless in Zone of Pain, 129 [part0027.html#page_129]
not all components should be, 123 [part0027.html#page_123]–125 [part0027.html#page_125]
placing high-level policies in, 126 [part0027.html#page_126]
Stable Abstractions Principle, 126 [part0027.html#page_126]–127 [part0027.html#page_127]
Stable Dependencies Principle. See SDP (Stable Dependencies Principle) [part0052.html#idx359]
Stakeholders
scope vs. shape for cost of change, 15 [part0012.html#page_15]
seniority of architecture over function, 18 [part0012.html#page_18]
values provided by software systems, 14 [part0012.html#page_14]
State
concurrency issues from mutation, 53 [part0017.html#page_53]
storing transactions but not, 54 [part0017.html#page_54]–55 [part0017.html#page_55]
Static analysis tools, architecture violations, 313 [part0049.html#page_313]
Static vs. dynamic polymorphism, 177 [part0032.html#page_177]
Strategy pattern
creating one-dimensional boundaries, 219 [part0038.html#page_219]
OO approach for cross-cutting concerns, 244 [part0041.html#page_244]–245 [part0041.html#page_245]
Streams, data
clean architecture and, 224 [part0039.html#page_224]–226 [part0039.html#page_226]
crossing, 226 [part0039.html#page_226]
splitting, 227 [part0039.html#page_227]–228 [part0039.html#page_228]
Structural coupling, testing API, 252 [part0042.html#page_252]
Structure. See Architecture [part0052.html#idx19]
Structured programming
Dijkstra’s proclamation on goto statements, 28 [part0015.html#page_28]–29 [part0015.html#page_29]
discipline of proof, 27 [part0015.html#page_27]–28 [part0015.html#page_28]
functional decomposition in, 29 [part0015.html#page_29]
history of, 22 [part0014.html#page_22]
lack of formal proofs, 30 [part0015.html#page_30]
overview of, 26 [part0015.html#page_26]
role of science in, 30 [part0015.html#page_30]–31 [part0015.html#page_31]
role of tests in, 31 [part0015.html#page_31]
value of, 31 [part0015.html#page_31]–32 [part0015.html#page_32]
Substitution
LSP. See LSP (Liskov Substitution Principle) [part0052.html#idx243]
programming to interfaces and, 271 [part0043.html#page_271]–272 [part0043.html#page_272]
Subtypes, defining, 78 [part0021.html#page_78]
T
Target-hardware bottleneck, 261 [part0043.html#page_261], 262 [part0043.html#page_262]–272 [part0043.html#page_272]
TAS (Teradyne Applied Systems), 334 [part0051.html#page_334]–338 [part0051.html#page_338], 339 [part0051.html#page_339]–344 [part0051.html#page_344]
Template Method pattern, OO approach for cross-cutting concerns, 244 [part0041.html#page_244]–245 [part0041.html#page_245]
Test boundary
conclusion, 253 [part0042.html#page_253]
designing for testability, 251 [part0042.html#page_251]
Fragile Tests Problem, 251 [part0042.html#page_251]
overview of, 249 [part0042.html#page_249]–250 [part0042.html#page_250]
testing API, 252 [part0042.html#page_252]–253 [part0042.html#page_253]
tests as system components, 250 [part0042.html#page_250]
Testable architecture
clean architecture creating, 202 [part0036.html#page_202]
clean embedded architecture as, 262 [part0043.html#page_262]–272 [part0043.html#page_272]
overview of, 198 [part0035.html#page_198]
Testing
and architecture, 213 [part0037.html#page_213]
Presenters and Views, 212 [part0037.html#page_212]–213 [part0037.html#page_213]
in structured programming, 31 [part0015.html#page_31]
unit. See Unit testing [part0052.html#idx423]
via Humble Object pattern, 212 [part0037.html#page_212]
Threads
mutability and, 52 [part0017.html#page_52]
schedule/order of execution, 179 [part0032.html#page_179]
Three-tiered “architecture” (as topology), 161 [part0031.html#page_161]
Top-down design, component structure, 118 [part0027.html#page_118]–119 [part0027.html#page_119]
Transactional memory, 53 [part0017.html#page_53]
Transactions, storing, 54 [part0017.html#page_54]–55 [part0017.html#page_55]
Transitive dependencies, violating software principles, 75 [part0020.html#page_75]
Trouble tickets, CDS archaeology project, 362 [part0051.html#page_362]–364 [part0051.html#page_364]
True duplication, 154 [part0030.html#page_154]–155 [part0030.html#page_155]
Turning, Alan, 23 [part0014.html#page_23]
U
UI (user interface). See also GUI (graphical user interface) [part0052.html#idx190]
applying LSP to, 80 [part0021.html#page_80]
clean architecture independent from, 202 [part0036.html#page_202]
crossing circle boundaries, 206 [part0036.html#page_206]
decoupling business rules from, 287 [part0046.html#page_287]–289 [part0046.html#page_289]
decoupling layers, 152 [part0030.html#page_152]–153 [part0030.html#page_153]
decoupling use cases, 153 [part0030.html#page_153]
Hunt the Wumpus adventure game, 222 [part0039.html#page_222]–223 [part0039.html#page_223]
independent developability, 47 [part0016.html#page_47], 154 [part0030.html#page_154]
Interface Segregation Principle, 84 [part0022.html#page_84]
programming to, 271 [part0043.html#page_271]–272 [part0043.html#page_272]
reducing volatility of, 88 [part0023.html#page_88]
SAC archaeology project, 346 [part0051.html#page_346]
UML class diagram
package by layer, 304 [part0049.html#page_304]–305 [part0049.html#page_305], 310 [part0049.html#page_310]
ports and adapters, 308 [part0049.html#page_308]–310 [part0049.html#page_310]
relaxed layered architecture, 311 [part0049.html#page_311]–312 [part0049.html#page_312]
Uncle Bob, 367 [part0051.html#page_367], 369 [part0051.html#page_369]
UNIFY database system, VRS archaeology project, 358 [part0051.html#page_358]–359 [part0051.html#page_359]
Union Accounting system, archaeology project, 326 [part0051.html#page_326]–334 [part0051.html#page_334]
Unit testing
creating testable architecture, 198 [part0035.html#page_198]
effect of cycle in component dependency graph, 116 [part0027.html#page_116]–117 [part0027.html#page_117]
via Humble Object pattern, 212 [part0037.html#page_212]
UNIX, IO device driver functions, 41 [part0016.html#page_41]–44 [part0016.html#page_44]
Upgrades, risks of frameworks, 293 [part0047.html#page_293]
Urgency, Eisenhower’s matrix of importance vs., 16 [part0012.html#page_16]–17 [part0012.html#page_17]
Use cases
architecture must support, 148 [part0030.html#page_148]
business rules for, 191 [part0034.html#page_191]–194 [part0034.html#page_194]
clean architecture scenario, 207 [part0036.html#page_207]–208 [part0036.html#page_208]
coupling to premature decisions with, 160 [part0031.html#page_160]
creating testable architecture, 198 [part0035.html#page_198]
crossing circle boundaries, 206 [part0036.html#page_206]
decoupling, 152 [part0030.html#page_152]
decoupling mode, 153 [part0030.html#page_153]
Dependency Rule for, 204 [part0036.html#page_204]
duplication of, 155 [part0030.html#page_155]
good architecture centered on, 196 [part0035.html#page_196], 197 [part0035.html#page_197]
independent developability and, 154 [part0030.html#page_154]
video sales case study, 298 [part0048.html#page_298]–300 [part0048.html#page_300]
User interface
GUI. See GUI (graphical user interface) [part0052.html#idx190]
UI. See UI (user interface) [part0052.html#idx418]
Utility library, Zone of Pain, 129 [part0027.html#page_129]
Uucp connection, 366 [part0051.html#page_366]
V
Values, software system
architecture (structure), 14 [part0012.html#page_14]–15 [part0012.html#page_15]
behavior, 14 [part0012.html#page_14]
Eisenhower’s matrix of importance vs. urgency, 16 [part0012.html#page_16]–17 [part0012.html#page_17]
fighting for seniority of architecture, 18 [part0012.html#page_18]
function vs. architecture, 15 [part0012.html#page_15]–16 [part0012.html#page_16]
overview of, 14 [part0012.html#page_14]
Variables, functional language, 51 [part0017.html#page_51]
Varian 620/f minicomputer, Union Accounting archaeology project, 331 [part0051.html#page_331]–334 [part0051.html#page_334]
Video sales case study
component architecture, 300 [part0048.html#page_300]–302 [part0048.html#page_302]
conclusion, 302 [part0048.html#page_302]
dependency management, 302 [part0048.html#page_302]
on process/decisions of good architect, 297 [part0048.html#page_297]–298 [part0048.html#page_298]
product, 298 [part0048.html#page_298]
use case analysis, 298 [part0048.html#page_298]–300 [part0048.html#page_300]
View Model, Presenters and Views, 213 [part0037.html#page_213]
Views
component architecture, 301 [part0048.html#page_301]
Presenters and, 212 [part0037.html#page_212]–213 [part0037.html#page_213]
Vignette Grande, architects registry exam, 371 [part0051.html#page_371]–372 [part0051.html#page_372]
Visual Studio, plugin argument, 172 [part0031.html#page_172]–173 [part0031.html#page_173]
Voice technologies, archaeology projects
Electronic Receptionist, 359 [part0051.html#page_359]–361 [part0051.html#page_361]
Voice Response System, 357 [part0051.html#page_357]–359 [part0051.html#page_359]
Volatile components
dependency graph and, 118 [part0027.html#page_118]
design for testability, 251 [part0042.html#page_251]
placing in volatile software, 126 [part0027.html#page_126]
as problematic in Zone of Pain, 129 [part0027.html#page_129]
Stable Dependencies Principle and, 120 [part0027.html#page_120]
Von Neumann, 34 [part0016.html#page_34]
VRS (Voice Response System), archaeology projects, 357 [part0051.html#page_357]–359 [part0051.html#page_359], 362 [part0051.html#page_362]–363 [part0051.html#page_363]
W
Web
as delivery system for your application, 197 [part0035.html#page_197]–198 [part0035.html#page_198]
Dependency Rule for, 205 [part0036.html#page_205]
is detail, 285 [part0046.html#page_285]–289 [part0046.html#page_289]
Web servers
creating testable architecture without, 198 [part0035.html#page_198]
as option to be left open, 141 [part0029.html#page_141], 197 [part0035.html#page_197]
writing own, 163 [part0031.html#page_163]–165 [part0031.html#page_165]
Weekly build, 112 [part0027.html#page_112]–113 [part0027.html#page_113]
Wiki text, architectural success story, 164 [part0031.html#page_164]
Y
Yourdon, Ed, 29 [part0015.html#page_29]
Z
Zones of exclusion
avoiding, 130 [part0027.html#page_130]
relationship between abstraction/stability, 128 [part0027.html#page_128]
Zone of Pain, 129 [part0027.html#page_129]
Zone of Uselessness, 129 [part0027.html#page_129]–130 [part0027.html#page_130]