Numbers
3DBB shared memory system, Craft Dispatch System archaeology project, 367
4-TEL, archaeology projects
SAC (service area computer), 348β353
8085 computer, archaeological projects
4-TEL, 345
BOSS, 355
DLU/DRU, 360
8086 Intel microcomputer, SAC archaeology project, 351β352
A
Abstract classes
conclusion, 132
Dependency Inversion Principle and, 87
leftover in Zone of Uselessness, 129β130
placing high-level policy, 126β128
services in Java as set of, 246
Abstract components, 125β126
Abstractions
principle of stable. See SAP (Stable Abstractions Principle)
source code dependencies and, 87
Access modifiers, architectural packages, 316β319
Accidental duplication, 154β155
Address segments, relocatable binaries, 99β100
ADP (Acyclic Dependencies Principle)
component dependency graph effected by, 118
effect of cycle in component dependency graph, 115β117
eliminating dependency cycles, 113β115
jitters, 118
overview of, 112
Aluminum die-cast monitoring, archaeology project, 342β343
Application-specific business rules, use cases, 192β193, 204
Architects
goal to minimize human resources, 160
registry exam archaeology project, 370β373
separate details from policy, 142
Architecture
clean. See Clean architecture
clean embedded. See Clean embedded architecture
design vs., 4
in DLU/DRU archaeology project, 360
Eisenhowerβs matrix of importance vs. urgency, 16β17
getting software right, 2
immutability and, 52
independence. See Independence
ISP and, 86
LSP and, 80
in ROSE archaeology product, 372β374
in SAC archaeology project, 349β351
as senior to function, 18
testing, 213
three big concerns in, 24
value of function vs., 15β16
in VRS archaeology project, 362β363
Architecture archaeology projects
aluminum die-cast monitoring, 342β343
architects registry exam, 374β377
by author since 1970, 329β330
Basic Operating System and Scheduler, 355β356
conclusion, 377
Craft Dispatch System, 365β371
Electronic Receptionist, 363β365
service area computer, 348β353
Union Accounting system, 330β338
Architecture, defining
conclusion, 146
deployment, 138
device independence, 142β143
keeping options open, 140β142
physical addressing example, 145β146
Architecture, screaming
conclusion, 199
frameworks as tools, not ways of life, 198
purpose of, 197
testable architectures, 198
Archives, as aggregation of components, 96
Artifacts, OCP, 70
ASC Tabulating, Union Accounting archaeology project, 330β338
Assignment, and functional programming, 23
Asymmetric marriage, to framework authors, 292β293
Automated systems, business rules, 191β192
B
Base classes, frameworks, 293
BCE system architecture, 202
Behavior (function)
architecture supports system, 137, 148
Eisenhowerβs matrix of importance vs. urgency, 16β17
fighting for seniority of architecture over function, 18
keeping options open, 140β142
as software value, 14
value of function vs. architecture, 15β16
Binaries, relocatability, 99β100
Booch, Grady
introduction to, 370
working for, 371
working on ROSE product, 372β373
BOSS (Basic Operating System and Scheduler)
archaeology project, 355β356
in DLU/DRU archaeology project, 360
Boundaries
in 4-TEL archaeology project, 344β345
conclusion, 173
dividing services into components, 246
in Electronic Receptionist archaeology project, 365
in Laser Trim archaeology project, 342
layers and. See Layers and boundaries
plugin architecture, 170β171
sad stories of architectural failures, 160β163
services as function calls across, 240
Union Accounting system archaeology project, 337β338
which lines to draw, and when, 165β169
boundary crossing, 176
conclusion, 181
deployment components, 178β179
threads, 179
Boundary crossing
in clean architecture, 206
clean architecture scenario, 207β208
creating appropriate, 176
Dependency Rule for data in, 207
Breaking cycle, Acyclic Dependencies Principle, 117β118
Business managers
Eisenhowerβs matrix of importance vs. urgency, 17
preference for function vs. architecture, 15β16
Business rules
boundaries between GUI and, 169β170
clean architecture for, 202β203
conclusion, 194
decoupling use cases, 153
designing for testability, 251
in Hunt the Wumpus adventure game, 222β223
independent developability, 47
keeping close to data, 67
policy statements calculating, 184
request/response models and, 193β194
in SAC archaeology project, 350β351
separating components with boundary lines, 165β169
C
C++ language
inheritance in, 40
learning, 370
marrying STL framework in, 293
polymorphism in, 42
weakening encapsulation, 36β37
C language
BOSS archaeology project using, 355β356
DLU/DRU archaeology project using, 360
C language, archaeology project, 353β355
C# programming language
abstract components in, 125
dependency inversion, 45
using statements for dependencies, 184
weakening encapsulation, 36β37
C Programming Language (Kernighan & Ritchie), 355
C4 software architecture model, 314β315
Carew, Mike, 360
CASE (Computer Aided Software Engineering) tool, 372
Case study. See Video sales case study
Cathode ray tube (CRT) terminals, Union Accounting archaeology project, 332β333
CCP (Common Closure Principle)
decoupling layers, 152
grouping policies into components, 186β187
keeping changes localized, 118
Stable Dependencies Principle and, 120
CCU/CMU (COLT control unit/COLT measurement unit), pCCU archaeology project, 357β358
CDS (Craft Dispatch System), archaeology project
Central office line testers. See COLTs (central office line testers)
Central offices (COs), 4-TEL archaeology project, 343β344
Change, ease of software, 14β15
CICS-COBOL program, aluminum die-cast archaeology project, 343
Classes
abstract. See Abstract classes
Common Reuse Principle, 107β108
DIP and, 89
LSP use in guiding inheritance, 78
partitioning processes into, 71β72
Reuse/Release Equivalence Principle, 105
SRP examples, 67
Clean architecture
conclusion, 209
frameworks tend to violate, 293
typical scenario, 208
using layers and boundaries, 223β226
Clean embedded architecture
conclusion, 273
donβt reveal hardware details to user of HAL, 265β269
DRY conditional compilation directives, 272
is testable embedded architecture, 262
operating system is detail, 269β271
programming to interfaces and substitutability, 271β272
target-hardware bottleneck, 261
Clear Communications, 368β371
phone call, 371
setup, 370
Uncle Bob, 371
Codd, Edgar, 278
Code
in aluminum die-cast archaeology project, 342β343
decreasing productivity/increased cost of, 5β7
foolishness of overconfidence, 9β12
rising costs of development payroll, 8β9
in SAC archaeology project, 349
source code dependencies. See Source code dependencies
Code organization
conclusion, 321
devil is in the details, 315β316
other decoupling modes, 319β320
package by component, 310β315
Cohesion, Single Responsibility Principle, 63
COLTs (central office line testers)
in 4-TEL archaeology project, 344β348
pCCU archaeology project, 356β358
in service area computer archaeology project, 348β353
Common Closure Principle. See CCP (Common Closure Principle)
Common Reuse Principle. See CRP (Common Reuse Principle)
Communications
across deployment component boundaries, 179
across local process boundaries, 180
across service boundaries, 180β181
across source-level decoupled boundaries, 178
Conwayβs law, 149
as function calls between components in monoliths, 178
in types of decoupling modes, 155β157
Compare and swap algorithm, 54
Compiled languages, 96
Compilers
enforce architectural principles with, 319
location of source code, 97β98
relocatable binaries, 99β100
Component architecture, video sales case study, 300β302
Component-based systems
building scalable, 241
designing services using SOLID, 245β246
function calls, 240
OO approach for cross-cutting concerns, 244β245
Component cohesion
Common Closure Principle, 105β107
Common Reuse Principle, 107β108
conclusion, 110
overview of, 104
Reuse/Release Equivalence Principle, 104β105
Component coupling
ADP. See ADP (Acyclic Dependencies Principle)
conclusion, 132
Fragile Tests Problem, 251
overview of, 111
Stable Abstractions Principle. See SAP (Stable Abstractions Principle)
Stable Dependencies Principle, 120β126
break cycle of components/reinstate as DAG, 117β118
Component-per-team architecture, 137β138
Components
concrete, 91
overview of, 96
partitioning processes into classes/separating classes into, 71β72
principles, 93
tests as system, 250
Computer Aided Software Engineering (CASE) tool, 368
Concrete components, Dependency Inversion Principle, 91
Concurrent tasks, BOSS archaeology project, 355β356
Constantine, Larry, 29
Control, flow of. See Flow of control
Control structures, program, 27β28
Control, transfer of, 22
Controllers
in clean architecture, 203, 205
clean architecture scenario, 207β208
crossing circle boundaries, 206
Conwayβs law, 149
Copper wires, pCCU archaeology project, 356β358
Core code, avoid frameworks in, 293
COs (central offices), 4-TEL archaeology project, 343β344
Coupling. See also Component coupling
avoid allowing framework, 293
to premature decisions, 160
Craft Dispatch System. See CDS (Craft Dispatch System), archaeology project
Critical Business Data, 190β191
Critical Business Rules, 190β193
Cross-cutting concerns
designing services to deal with, 247
object-oriented approach to, 244β245
Crossing data streams, 226
CRP (Common Reuse Principle)
influencing composition of components, 118
CRT (cathode ray tube) terminals, Union Accounting archaeology project, 332β333
Cycles
effect of in dependency graph, 115β117
eliminating dependency, 113β115
weekly build issues, 112β113
D
D metric, distance from Main Sequence, 130β132
DAGs (directed acyclic graphs)
architectural framework for policy, 184
breaking cycle of components, 117β118
defined, 114
Dahl, Ole Johan, 22
clean architecture scenario, 207β208
Dependency Rule for crossing boundaries, 207
management concerns in architecture, 24
separating from functions, 66
Data model, database vs., 278
Data storage
in Laser Trim archaeology project, 339
prevalence of database systems due to disks, 279β280
in Union Accounting archaeology project, 331β332
Database
clean architecture independent from, 202
clean architecture scenario, 207β208
creating testable architecture without, 198
decoupling layers, 153
decoupling use cases, 153
Dependency Rule, 205
drawing boundary line between business rules and, 165
gateways, 214
in Hunt the Wumpus adventure game, 222β223
independent developability, 47
leaving options open in development, 141, 197
plugin architecture, 171
relational, 278
schema in Zone of Pain, 129
separating components with boundary lines, 165β169
Database is detail
conclusion, 283
details, 281
if there were no disks, 280β281
performance, 281
relational databases, 278
why database systems are so prevalent, 279β280
DCI system architecture, 202
Deadlocks, from mutable variables, 52
Decoupling
as fallacy of services, 240β241
independent deployment, 154, 241
independent development, 153β154, 241
kitty problem example, 242β243
OO approach for cross-cutting concerns, 244β245
purpose of testing API, 252β253
source code dependencies, 323
use cases, 152
DeMarco, Tom, 29
Dependencies
ADP. See ADP (Acyclic Dependencies Principle)
architectural framework for policy, 184
calculating stability metrics, 123
case study. See Video sales case study
Common Reuse Principle and, 107β108
DIP. See DIP (Dependency Inversion Principle)
in Laser Trim archaeology project, 338
OCP example, 72
in package by layer, 304β306, 310β311
software destroyed by unmanaged, 256
stable. See SDP (Stable Dependencies Principle)
transitive, 75
understanding component, 121
in Union Accounting archaeology project, 337β338
Dependency Injection framework, Main component, 232
Dependency management
metrics. See ADP (Acyclic Dependencies Principle)
via full-fledged architectural boundaries, 218
via polymorphism in monolithic systems, 177
video sales case study, 302
Dependency Rule
clean architecture and, 203β206
clean architecture scenario, 207β208
crossing boundaries, 206
defined, 91
dependency management, 302
designing services to follow, 247
Entities, 204
frameworks and drivers, 205
frameworks tending to violate, 293
in Hunt the Wumpus adventure game, 223
interface adapters, 205
OO approach for cross-cutting concerns, 244β245
services may follow, 240
tests following, 250
use cases, 204
which data crosses boundaries, 207
Deployment
architecture determines ease of, 150
components as units of, 96
impact of architecture on, 138
tests use independent, 250
Deployment-level decoupling mode, 156β157, 178β179
Design
approaches to. See Code organization
architecture vs., 4
decreasing productivity/increases cost of code, 5β7
getting it right, 2
reducing volatility of interfaces, 88
for testability, 251
Designing Object-Oriented C++ Applications Using the Booch Method, 373
Detail
database is. See Database is detail
donβt reveal hardware, to user of HAL, 265β269
separating from policy, 140β142
story of architectural success, 163β165
Developers
decreasing productivity/increasing cost of code, 5β7
Eisenhowerβs matrix of importance vs. urgency, 17
foolishness of overconfidence, 9β12
preference for function vs. architecture, 15β16
scope vs. shape in determining cost of change, 15
as stakeholders, 18
Development
impact of architecture on, 137β138
independent. See Independent developability
role of architecture in supporting, 149β150
role of test to support, 250
Device independence
physical addressing example, 145β146
in programming, 44
Digital revolution, and telephone companies, 356β358
Dijkstra, Edsger Wybe
applying discipline of proof to programming, 27
discovery of structured programming, 22
history of, 26
proclamation on goto statements, 28β29
on testing, 31
DIP (Dependency Inversion Principle)
breaking cycle of components, 117β118
conclusion, 91
concrete components, 91
crossing circle boundaries, 206
defined, 59
drawing boundary lines, 173
Entities without knowledge of use cases as, 193
in good software architecture, 71
not all components should be stable, 125
Stable Abstractions Principle, 127
Directed acyclic graph. See DAGs (directed acyclic graphs)
Directional control, Open-Closed Principle, 74
Disks
prevalence of database systems due to, 279β280
in Union Accounting archaeology project, 330β334
Dispatch code, service area computer project, 349
Display local unit/display remote unit (DLU/DRU) archaeology project, 358β360
DLU/DRU (display local unit/display remote unit), archaeology project, 358β360
Do/while/until statements, 22, 27
Donβt Repeat Yourself (DRY) principle, conditional compilation directives, 272
Drawing lines. See Boundaries
Drivers, Dependency Rule, 205
DRY (Donβt Repeat Yourself) principle, conditional compilation directives, 272
DSL (domain-specific data-driven language), Laser Trim archaeology project, 341
Duplication
true vs. accidental, 154β155
Dynamic polymorphism, 177β178, 206
Dynamically linked libraries, as architectural boundaries, 178β179
Dynamically typed languages
DIP and, 88
ISP and, 85
E
Editing, Laser Trim archaeology project, 340
Educational Testing Service (ETS), 374β376
Eisenhower, matrix of importance vs. urgency, 16β17
Embedded architecture. See Clean embedded architecture
Encapsulation
overuse of public and, 316
Entities
clean architecture scenario, 207β208
creating testable architecture, 198
Dependency Rule for, 204
risks of frameworks, 293
Enumeration, Dijkstraβs proof for sequence/selection, 28
EPROM (Erasable Programmable Read-Only Memory) chips, 4-TEL archaeology project, 345β347
ER (Electronic Receptionist)
archaeology project, 363β365
Craft Dispatch System was, 366β368
ETS (Educational Testing Service), 374β376
Europe, redesigning SAC for US and, 351β352
Event sourcing, storing transactions, 54β55
Executables
deployment of monoliths, 176β178
linking components as, 96
External agency, clean architecture independence from, 202
External definition, compilers, 100
External reference, compilers, 100
F
Facade pattern, partial boundaries, 220
Fan-in/fan-out metrics, component stability, 122β123
Feathers, Michael, 58
File systems, mitigating time delay, 279β280
Firewalls, boundary crossings via, 176
Firmware
in 4-TEL archaeology project, 347β348
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
FLD (Field Labeled Data), Craft Dispatch System archaeology project, 367
Flow of control
crossing circle boundaries, 206
dependency management, case study, 302
dynamic polymorphism, 177β178
in Union Accounting archaeology project, 338
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
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
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, 330β334
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
GUI (graphical user interface). See also UI (user interface)
decoupling business rules from, 287β289
designing for testability, 251
developing architects registry exam, 375β376
input/output and boundary lines, 169β170
plugin architecture, 170β171
separating from business rules with boundaries, 165β169
unit testing, 212
web is, 288
H
HAL (hardware abstraction layer)
avoid revealing hardware details to user of, 265β269
as boundary line between software/firmware, 264
DRY conditional compilation directives, 272
operating system is detail and, 269β271
Hardware
eliminating target-hardware bottleneck with layers, 262β263
firmware becomes obsolete through evolution of, 256
in SAC archaeology project, 350β351
Header files, programming to interfaces with, 272
Hexagonal Architecture (Ports and Adapters), 202
High-level policy
decoupling from lower level input/output policies, 185β186
separating details from, 140β142
splitting data streams, 227β228
where to place, 126
Human resources, goal of architect to minimize, 160
Humble Object pattern
database getaways, 214
Presenters and Views, 212β213
Presenters as form of, 212
testing and architecture, 213
understanding, 212
Hunt the Wumpus game
layers and boundaries. See Layers and boundaries
Main component from, 232β237
I
IBM System/7, aluminum die-cast archaeology project, 342β343
If/then/else statements, 22, 27
Implementation strategy. See Code organization
Importance, urgency vs. Eisenhowerβs matrix of, 16β17
Incoming dependencies, stability metrics, 122β123
Independence
conclusion, 158
decoupling mode, 153
decoupling use cases, 152
deployment, 150
independent deployability, 154
independent developability, 153β154
leaving options open, 150β151
operation, 149
types of decoupling modes, 155β158
use cases, 148
Independent components
calculating stability metrics, 123
understanding, 121
Independent deployability
in 4-TEL archaeology project, 348
as fallacy of services, 241
kitty problem example, 242β243
in OO approach for cross-cutting concerns, 244β245
overview of, 154
Independent developability
as fallacy of services, 241
kitty problem example, 242β243
in OO approach for cross-cutting concerns, 244β245
of UI and database, 47
Induction, Dijkstraβs proof related to iteration, 28
Information hiding, Open-Closed Principle, 74β75
Inheritance relationships
crossing circle boundaries, 206
dependency inversion, 46
dependency management, 302
guiding use of, 78
Input/output
business rules for use cases, 193β194
decoupling higher-level policy from lower level, 185β187
policy level defined as distance from, 184
separating components with boundary lines, 169β170
Integers, functional programming example, 50β51
Integration, weekly build issues, 112β113
Interface adapters, Dependency Rule for, 205
Interface Segregation Principle. See ISP (Interface Segregation Principle)
IO device
ISP (Interface Segregation Principle)
architecture and, 86
Common Reuse Principle compared with, 108
conclusion, 86
defined, 59
language type and, 85
J
Jar files
component architecture, 301
components as, 96
creating partial boundary, 219
defining function of components, 313
designing component-based services, 245β246
Download and Go rule for, 163
in source-level decoupling mode, 176
Java
abstract components in, 125
code organization approaches in. See Code organization
components as jar files in, 96
DIP and, 87
import statements for dependencies, 184
marrying standard library framework in, 293
module frameworks in, 319
package by layer in, 304β306
squares of integers example in, 50β51
weakening encapsulation, 36β37
Jitters, breaking cycle of components, 118
K
Kitty problem example, 242β245
L
Languages
clean architecture and, 223β226
Hunt the Wumpus adventure game, 222β223
Laser Trim, archaeology project
4-TEL project, 343
Layered architecture
package by layer code organization, 304β306
why it is considered bad, 310β311
Layers
approach to code organization, 304β306
clean architecture using, 202β203
duplication of, 155
eliminating target-hardware bottleneck, 262β263
independent developability, 154
Layers and boundaries
conclusion, 228
crossing streams, 226
Hunt the Wumpus adventure game, 222β223
Leiningen tool, module management, 104
Level
hierarchy of protection and, 74
Libraries
location of source code, 97β98
relocatable binaries, 99β100
Life cycle, architecture supports system, 137
Linkers, separating from loaders, 100β102
Liskov, Barbara, 78
Liskov Substitution Principle (LSP). See LSP (Liskov Substitution Principle)
LISP langauge, functional programming, 23
Lisp language, squares of integers example, 50β51
Loaders
relocatable binaries, 99β100
Local process boundaries, 179β180
LSP (Liskov Substitution Principle)
architecture and, 80
conclusion, 82
defined, 59
guiding use of inheritance, 78
overview of, 78
square/rectangle example problem, 79
M
M365 computer
4-TEL archaeology project, 344β345
Laser Trim archaeology project, 339β342
SAC archaeology project, 349β351
Mailboxes, local processes communicate via, 180
Main component
conclusion, 237
as concrete component, 91
defined, 232
object-oriented programming, 40
polymorphism, 45
small impact of releasing, 115
Main Sequence
avoiding Zones of Exclusion via, 130
defining relationship between abstraction/stability, 127β128
measuring distance from, 130β132
Zone of Pain, 129
Zone of Uselessness, 129β130
Maintenance, impact of architecture on, 139β140
Marketing campaigns, database vendor, 283
Master Operating Program (MOP), Laser Trim archaeology project, 340
Mathematics
contrasting science with, 30
Maven tool, module management, 104
McCarthy, John, 23
Memory
local processes and, 179
RAM. See RAM
Merges, SRP examples, 65
Message queues, local processes communicate via, 180
Metrics
abstraction, 127
distance from Main Sequence, 130β132
Meyer, Bertrand, 70
Micro-service architecture
in Craft Dispatch System archaeology project, 366β367
decoupling mode, 153
deployment strategy, 138
popularity of, 239
Modems, SAC archaeology project, 350β351
Modules
Common Reuse Principle, 107β108
defined, 62
management tools, 104
public types vs. published types, 319
Reuse/Release Equivalence Principle, 105
Monoliths
building scalable systems, 241
deployment-level components vs., 179
function calls, 240
local processes as statically linked, 180
threads, 179
Mooreβs Law, 101
MOP (Master Operating Program), Laser Trim archaeology project, 340
Morning after syndrome
eliminating dependency cycles to solve, 113β115
managing dependencies to prevent, 118
overview of, 112
weekly build issues, 112β113
MPS (multiprocessing system), SAC archaeology project, 349β350
Mutable variables, 51, 54β55
N
National Council of Architects Registry Board (NCARB), 374β376
.NET, components as DLLs, 96
NetNews, presence of author on, 371β373
Nygaard, Kristen, 22
O
Object-oriented databases, ROSE product, 372β374
Object Oriented Design with Applications (Booch), 370, 372
Object-oriented programming
conclusion, 47
for cross-cutting concerns, 244β245
deployment of monoliths, 177
history of, 22
power of polymorphism, 43β44
Object Oriented Software Engineering (Jacobson), 196, 202
Object relational mappers (ORMs), 214β215
Objects, invented in 4-TEL archaeology project, 348
OCP (Open-Closed Principle)
birth of, 142
Common Closure Principle compared with, 106
conclusion, 75
in Craft Dispatch System archaeology project, 367
defined, 59
dependency management, 302
designing component-based services, 246
directional control, 74
overview of, 70
OMC (Outboard Marine Corporation), aluminum die-cast archaeology project, 342β343
One-dimensional boundaries, 219
Open-Closed Principle. See OCP (Open-Closed Principle)
Operating system abstraction layer (OSAL), clean embedded architecture, 270β271
Operating system (OS), is detail, 269β271
Operations
architecture supports system, 138β139, 149
decoupling use cases for, 153
use cases affected by changes in, 204
Options, keeping open
good architecture makes system easy to change, 150β151
operational architecture, 149
purpose of architecture, 140β142, 197
via decoupling mode, 153
Organization vs. encapsulation, 316β319
ORMs (object relational mappers), 214β215
OS (operating system), is detail, 269β271
OSAL (operating system abstraction layer), clean embedded architecture, 270β271
Oscillations, web as one of many, 285β289
Outgoing dependencies, stability metrics, 122β123
Overconfidence, foolishness of, 9β12
P
Package by component, 310β315, 318
Package by feature, 306β307, 317
Package by layer
horizontal layering of code, 304β306
why it is considered bad, 310β311
Packages, organization vs. encapsulation, 316β319
Page-Jones, Meilir, 29
Partial boundaries
conclusion, 220
facades, 220
one-dimensional boundaries, 219
reasons to implement, 217β218
Patches, in 4-TEL archaeology project, 348
PCCU, archaeology project, 356β358
Performance, as low-level concern, 281
PΓ©riphΓ©rique anti-pattern of ports and adapters, 324β325
Physical addressing example, 145β146
Plugin architecture
in 4-TEL archaeology project, 348
for device independence, 44
drawing boundaries for axis of change, 173
of lower-level components into higher-level components, 187
Main component as, 237
start with presumption of, 170β171
Pointers
in creating polymorphic behavior, 43
Policy
in clean architecture, 203
high-level. See High-level policy
software systems as statements of, 183
splitting data streams, 227β228
Polymorphic dispatch, 4-TEL archaeology project, 348
Polymorphism
crossing circle boundaries with dynamic, 206
flow of control in dynamic, 177β178
in object-oriented programming, 22, 40β43
Ports and adapters
access modifiers, 318
approach to code organization, 308β310
decouple dependencies with source code trees, 319β320
PΓ©riphΓ©rique anti-pattern of, 320β321
Positional stability, component, 122β123
Premature decisions, coupling to, 160β163
βPresentation Domain Data Layeringβ (Fowler), 305β306
Presenters
in clean architecture, 203, 205
clean architecture scenario, 207β208
component architecture, 301
crossing circle boundaries, 206
Presenters and humble objects
conclusion, 215
database getaways, 214
Humble Object pattern, 212
Presenters and Views, 212β213
service listeners, 215
testing and architecture, 213
Processes, partitioning into classes/separating classes, 71β72
Processor
mutability and, 52
Product, video sales case study, 298
Productivity
decreasing, increasing cost of code, 5β7
Programming languages
abstract components in, 125β126
components, 96
dynamically typed, 88
ISP and, 85
statically typed, 87
variables in functional languages, 51
Programming paradigms
functional programming. See Functional programming
object-oriented programming. See Object-oriented programming
structured programming. See Structured programming
Proof
structured programming lacking, 30β31
Proxies, using with frameworks, 293
Public types
vs. types that are published in modules, 319
Python
DIP and, 88
ISP and, 85
R
Race conditions
due to mutable variables, 52
protecting against concurrent updates and, 53
4-TEL archaeology project, 345, 347β348
RDBMS (relational database management systems), 279β283
Real-time operating system (RTOS) is detail, 269β271
Relational database management systems (RDBMS), 279β283
Relational databases, 278, 281β283
Relaxed layered architecture, 311β312
Releases
effect of cycle in component dependency graph, 115β117
eliminating dependency cycles, 113β115
numbering new component, 113
Reuse/Release Equivalence Principle for new, 104β105
Remote terminals, DLU/DRU archaeology project, 358β360
REP (Reuse/Release Equivalence Principle), 104β105, 108β110
Request models, business rules, 193β194
ReSharper, plugin argument, 172β173
Response models, business rules, 193β194
REST, leave options open in development, 141
Reusability. See CRP (Common Reuse Principle)
Reuse/Release Equivalence Principle (REP), 104β105, 108β110
Risks
architecture should mitigate costs of, 139β140
ROM boards, 4-TEL archaeology project, 345
ROSE product, archaeology project, 372β374
RTOS (real-time operating system) is detail, 269β271
Ruby
components as gem files, 96
DIP and, 88
ISP and, 85
RVM tool, module management, 104
S
SAC (service area computer), archaeology project
conclusion, 353
dispatch determination, 349
DLU/DRU archaeology project, 358β360
overview of, 348
SAP (Stable Abstractions Principle)
avoiding zones of exclusion, 130
distance from main sequence, 130β132
drawing boundary lines, 173
measuring abstraction, 127
where to put high-level policy, 126
SC (service center), 4-TEL archaeology project, 343β344
kitty problem and services, 242β243
services not only option for building, 241
Scientific methods, proving statements false, 30β31
Scope, of changing architecture, 15
Screaming architecture. See Architecture, screaming
SDP (Stable Dependencies Principle)
abstract components, 125β126
not all components should be, 124β125
not all components should be stable, 123β125
overview of, 120
Stable Abstractions Principle, 127
Security, testing API, 253
Selection, as program control structure, 27β28
Separation of components, as big concern in architecture, 24
Sequence, as program control structure, 27β28
Serial communication bus, SAC archaeology project, 347
Service area computer. See SAC (service area computer), archaeology project
Service center (SC), 4-TEL archaeology project, 343β344
Service-level decoupling mode, 153, 156β157
Services
conclusion, 247
cross-cutting concerns, 246β247
as function calls vs. architecture, 240
Humble Object boundaries for, 214β215
independent development/deployment fallacy, 241
objects to the rescue, 244β245
overview of, 239
as strongest boundary, 180β181
Set program interrupt (SPI) instruction, aluminum die-cast archaeology project, 339
Shape, of change, 15
Single Responsibility Principle. See SRP (Single Responsibility Principle)
SOA (service-oriented architecture)
decoupling mode, 153
in Electronic Receptionist archaeology project, 364β365
reasons for popularity of, 239
Sockets, local processes communicate via, 180
Software
clean embedded architecture isolates OS from, 270
components. See Components
eliminating target-hardware bottleneck with layers, 262β263
fuzzy line between firmware and, 263β264
SOLID principles, 58
value of architecture vs. behavior, 14β18
Software development
fighting for architecture over function, 18
like a science, 31
Software reuse
Common Reuse Principle, 107β108
reusable components and, 104
Reuse/Release Equivalence Principle, 104β105
SOLID principles
Dependency Inversion Principle. See DIP (Dependency Inversion Principle)
designing component-based services using, 245β246
Interface Segregation Principle. See ISP (Interface Segregation Principle)
Liskov Substitution Principle. See LSP (Liskov Substitution Principle)
OO approach for cross-cutting concerns, 244β245
Open-Closed Principle. See OCP (Open-Closed Principle)
Single Responsibility Principle. See SRP (Single Responsibility Principle)
Source code, compiling, 97β98
Source code dependencies
creating boundary crossing via, 176
crossing circle boundaries, 206
local processes as, 180
OCP example, 72
referring only to abstractions, 87β88
UI components reuse game rules via, 222β223
Source code trees, decoupling dependencies, 319β321
Source-level decoupling mode, 155β157, 176β178
Spelunking, architecture mitigates costs of, 139β140
SPI (set program interrupt) instruction, aluminum die-cast archaeology project, 343
Splitting data streams, 227β228
Square/rectangle problem, LSP, 79
Squares of integers, functional programming, 50β51
SRP (Single Responsibility Principle)
accidental duplication example, 63β65
Common Closure Principle vs., 106β107
decoupling layers, 152
defined, 59
dependency management, 302
in good software architecture, 71
grouping policies into components, 186β187
keeping changes localized, 118
merges, 65
use case analysis, 299
where to draw boundaries, 172β173
Stability, component
relationship between abstraction and, 127β130
SAP. See SAP (Stable Abstractions Principle)
Stable Abstractions Principle. See SAP (Stable Abstractions Principle)
Stable components
abstract components as, 125β126
as harmless in Zone of Pain, 129
not all components should be, 123β125
placing high-level policies in, 126
Stable Abstractions Principle, 126β127
Stable Dependencies Principle. See SDP (Stable Dependencies Principle)
Stakeholders
scope vs. shape for cost of change, 15
seniority of architecture over function, 18
values provided by software systems, 14
State
concurrency issues from mutation, 53
storing transactions but not, 54β55
Static analysis tools, architecture violations, 313
Static vs. dynamic polymorphism, 177
Strategy pattern
creating one-dimensional boundaries, 219
OO approach for cross-cutting concerns, 244β245
Streams, data
clean architecture and, 224β226
crossing, 226
Structural coupling, testing API, 252
Structure. See Architecture
Structured programming
Dijkstraβs proclamation on goto statements, 28β29
functional decomposition in, 29
history of, 22
lack of formal proofs, 30
overview of, 26
role of tests in, 31
Substitution
LSP. See LSP (Liskov Substitution Principle)
programming to interfaces and, 271β272
Subtypes, defining, 78
T
Target-hardware bottleneck, 261, 262β272
TAS (Teradyne Applied Systems), 338β342, 343β348
Template Method pattern, OO approach for cross-cutting concerns, 244β245
conclusion, 253
designing for testability, 251
Fragile Tests Problem, 251
tests as system components, 250
Testable architecture
clean architecture creating, 202
clean embedded architecture as, 262β272
overview of, 198
Testing
and architecture, 213
Presenters and Views, 212β213
in structured programming, 31
unit. See Unit testing
via Humble Object pattern, 212
Threads
mutability and, 52
schedule/order of execution, 179
Three-tiered βarchitectureβ (as topology), 161
Top-down design, component structure, 118β119
Transactional memory, 53
Transactions, storing, 54β55
Transitive dependencies, violating software principles, 75
Trouble tickets, CDS archaeology project, 362β364
Turning, Alan, 23
U
UI (user interface). See also GUI (graphical user interface)
applying LSP to, 80
clean architecture independent from, 202
crossing circle boundaries, 206
decoupling business rules from, 287β289
decoupling use cases, 153
Hunt the Wumpus adventure game, 222β223
independent developability, 47, 154
Interface Segregation Principle, 84
reducing volatility of, 88
SAC archaeology project, 346
UML class diagram
package by layer, 304β305, 310
relaxed layered architecture, 311β312
UNIFY database system, VRS archaeology project, 362β363
Union Accounting system, archaeology project, 330β338
Unit testing
creating testable architecture, 198
effect of cycle in component dependency graph, 116β117
via Humble Object pattern, 212
UNIX, IO device driver functions, 41β44
Upgrades, risks of frameworks, 293
Urgency, Eisenhowerβs matrix of importance vs., 16β17
Use cases
architecture must support, 148
clean architecture scenario, 207β208
coupling to premature decisions with, 160
creating testable architecture, 198
crossing circle boundaries, 206
decoupling, 152
decoupling mode, 153
Dependency Rule for, 204
duplication of, 155
good architecture centered on, 196, 197
independent developability and, 154
video sales case study, 298β300
User interface
GUI. See GUI (graphical user interface)
UI. See UI (user interface)
Utility library, Zone of Pain, 129
Uucp connection, 370
V
Values, software system
architecture (structure), 14β15
behavior, 14
Eisenhowerβs matrix of importance vs. urgency, 16β17
fighting for seniority of architecture, 18
function vs. architecture, 15β16
overview of, 14
Variables, functional language, 51
Varian 620/f minicomputer, Union Accounting archaeology project, 335β339
Video sales case study
component architecture, 300β302
conclusion, 302
dependency management, 302
on process/decisions of good architect, 297β298
product, 298
View Model, Presenters and Views, 213
Views
component architecture, 301
Vignette Grande, architects registry exam, 375β376
Visual Studio, plugin argument, 172β173
Voice technologies, archaeology projects
Electronic Receptionist, 363β365
Voice Response System, 361β363
Volatile components
dependency graph and, 118
design for testability, 251
placing in volatile software, 126
as problematic in Zone of Pain, 129
Stable Dependencies Principle and, 120
Von Neumann, 34
VRS (Voice Response System), archaeology projects, 361β363, 366β367
W
Web
as delivery system for your application, 197β198
Dependency Rule for, 205
Web servers
creating testable architecture without, 198
as option to be left open, 141, 197
Wiki text, architectural success story, 164
Y
Yourdon, Ed, 29
Z
Zones of exclusion
avoiding, 130
relationship between abstraction/stability, 128
Zone of Pain, 129
Zone of Uselessness, 129β130
3.239.57.87