INDEX
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
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
in VRS archaeology project, 362–363
Architecture archaeology projects
aluminum die-cast monitoring, 342–343
architects registry exam, 374–377
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
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
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)
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
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
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
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
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
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
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)
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
FitNesse program
FLD (Field Labeled Data), Craft Dispatch System archaeology project, 367
Flow of control
crossing circle boundaries, 206
dependency management, case study, 302
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
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 as form of, 212
testing and architecture, 213
understanding, 212
Hunt the Wumpus game
layers and boundaries. See Layers and boundaries
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
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
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
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
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
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
MPS (multiprocessing system), SAC archaeology project, 349–350
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
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
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
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)
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 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
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
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