Clean Architecture

The Electronic Receptionist
361
When a call came in, an initial handler process was started and the call was 
passed to it. As the call proceeded from state to state, the appropriate handler 
process would be started and take control.
Messages were passed between these services through disk files. The currently 
running service would determine what the next service should be; would 
write the necessary state information into a disk file; would issue the 
command line to start that service; and then would exit.
This was the first time I had built a system like this. Indeed, this was the first 
time I had been the principal architect of an entire product. Everything having 
to do with software was mine—and it worked like a champ.
I would not say that the architecture of this system was “clean” in the sense 
of this book; it was not a “plugin” architecture. However, it definitely showed 
signs of true boundaries. The services were independently deployable, and 
lived within their own domain of responsibility. There were high-level 
processes and low-level processes, and many of the dependencies ran in the 
right direction.
E R D e m i s e
Unfortunately, the marketing of this product did not go very well. Teradyne 
was a company that sold test equipment. We did not understand how to 
break into the office equipment market.
After repeated attempts over two years, our CEO gave up and—
unfortunately—dropped the patent application. The patent was picked up by 
the company that filed three months after we filed; thus we surrendered the 
entire voice mail and electronic call-forwarding market.
Ouch!
On the other hand, you can’t blame me for those annoying machines that 
now plague our existence.
www.EBooksWorld.ir

---

Appendix A Architecture Archaeology