Clean Architecture

Index
386
Firmware (
continued
)
eliminating target-hardware 
bottleneck, 262–263
fuzzy line between software and, 
263–264
obsolete as hardware evolves, 256
stop writing so much, 257–258
FitNesse program
overview of, 163–165
partial boundary, 218–219
FLD (Field Labeled Data), Craft 
Dispatch System archaeology 
project, 363
Flow of control
crossing circle boundaries, 206
dependency management, case 
study, 302
dynamic polymorphism, 177–178
in Union Accounting archaeology 
project, 334
Fowler, Martin, 305–306
Fragile Tests Problem, 251
Frameworks
avoid basing architecture on, 197
clean architecture independent 
from, 202
creating testable architecture 
without, 198
Dependency Rule for, 205
as option to be left open, 197
as tools, not a way of life, 198
Frameworks are details
asymmetric marriage and, 292–293
conclusion, 295
framework authors, 292
frameworks you must simply 
marry, 295
popularity of, 292
risks, 293–294
solution, 294
Function calls, services as, 240
Functional decomposition
programming best practice, 32
in structured programming, 29
Functional pointers, OOP, 22, 23
Functional programming
conclusion, 56
event sourcing, 54–55
history of, 22–23
immutability, 52
overview of, 50
segregation of mutability, 52–54
squares of integers example, 
50–51
Functions
avoid overriding concrete, 89
breaking down into parts 
(functional decomposition), 29
one of three big concerns in 
architecture, 24
principle of doing one thing, 62
separating from data, 66
SRP examples, 67
G
Gateways, database, 214
GE Datanet 30 computer, Union 
Accounting archaeology project, 
326–330
Goto statements
Dijkstra replaces with iteration 
control structures, 27
Dijkstra’s proclamation on 
harmfulness of, 28–29
history of structured 
programming, 22
removed in structured 
programming, 23
Growing Object Oriented Software 
with Tests 
(Freeman & Pryce), 202
www.EBooksWorld.ir

---