Clean Architecture

Conclusion
373
Of course, both of these applications were statically linked C++ applications, 
so the notion of plugin was nowhere in our minds. And yet, the way the 
dependencies ran was consistent with the Dependency Rule.
Having delivered those four applications, we began on the next four. And this 
time they started popping out the back end every few weeks, just as we had 
predicted. The delay had cost us nearly a year on our schedule, so we hired 
another programmer to speed the process along.
We met our dates and our commitments. Our customer was happy. We were 
happy. Life was good.
But we learned a good lesson: You can’t make a reusable framework until you 
first make a usable framework. Reusable frameworks require that you build 
them in concert with 
several
reusing applications.
C o n c lu s i o n
As I said at the start, this appendix is somewhat autobiographical. I’ve hit the 
high points of the projects that I felt had an architectural impact. And, of 
course, I mentioned a few episodes that were not exactly relevant to the 
technical content of this book, but were significant nonetheless.
Of course, this was a partial history. There were many other projects that 
I worked on over the decades. I also purposely stopped this history in the 
early 1990s—because I have another book to write about the events of 
the late 1990s.
My hope is that you enjoyed this little trip down my memory lane; and that 
you were able to learn some things along the way.
www.EBooksWorld.ir

---

This page intentionally left blank 
www.EBooksWorld.ir

---

375
I n de x
Numbers
3DBB shared memory system, Craft 
Dispatch System archaeology 
project, 363
4-TEL, archaeology projects
BOSS, 351–352
C language, 349–351
DLU/DRU, 354–356
overview of, 339–344
pCCU, 352–354
SAC (service area computer), 
344–349
VRS, 357–359
8085 computer, archaeological 
projects
4-TEL, 341
BOSS, 351
C language and, 349–351
DLU/DRU, 356
8086 Intel microcomputer, 
SAC archaeology project, 
347–348
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
Abstract Factories, 89–90
Abstractions
principle of stable. 
See
SAP 
(Stable Abstractions Principle)
source code dependencies and, 87
stable, 88–89
Access modifiers, architectural 
packages, 316–319
Accidental duplication, 154–155
Actors, 62–65
Address segments, relocatable 
binaries, 99–100
www.EBooksWorld.ir

---