book

Clean Architecture: A Craftsman's Guide to Software Structure and Design

by Robert C. Martin

September 2017

Intermediate to advanced

432 pages

8h 20m

English

Pearson

Read now

Unlock full access

Includes

Has Sandbox

The Goal?Case StudyConclusion
BehaviorArchitectureThe Greater ValueEisenhower’s MatrixFight for the Architecture
Structured ProgrammingObject-Oriented ProgrammingFunctional ProgrammingFood for ThoughtConclusion
ProofA Harmful ProclamationFunctional DecompositionNo Formal ProofsScience to the RescueTestsConclusion
Encapsulation?Inheritance?Polymorphism?Conclusion
Squares of IntegersImmutability and ArchitectureSegregation of MutabilityEvent SourcingConclusion
Symptom 1: Accidental DuplicationSymptom 2: MergesSolutionsConclusion
A Thought ExperimentDirectional ControlInformation HidingConclusion
Guiding the Use of InheritanceThe Square/Rectangle ProblemLSP and ArchitectureExample LSP ViolationConclusion
ISP and LanguageISP and ArchitectureConclusion
Stable AbstractionsFactoriesConcrete ComponentsConclusion
A Brief History of ComponentsRelocatabilityLinkersConclusion
The Reuse/Release Equivalence PrincipleThe Common Closure PrincipleThe Common Reuse PrincipleThe Tension Diagram for Component CohesionConclusion
The Acyclic Dependencies PrincipleTop-Down DesignThe Stable Dependencies PrincipleThe Stable Abstractions PrincipleConclusion
DevelopmentDeploymentOperationMaintenanceKeeping Options OpenDevice IndependenceJunk MailPhysical AddressingConclusion
Use CasesOperationDevelopmentDeploymentLeaving Options OpenDecoupling LayersDecoupling Use CasesDecoupling ModeIndependent Develop-abilityIndependent DeployabilityDuplicationDecoupling Modes (Again)Conclusion
A Couple of Sad StoriesFitNesseWhich Lines Do You Draw, and When Do You Draw Them?What About Input and Output?Plugin ArchitectureThe Plugin ArgumentConclusion
Boundary CrossingThe Dreaded MonolithDeployment ComponentsThreadsLocal ProcessesServicesConclusion
LevelConclusion
EntitiesUse CasesRequest and Response ModelsConclusion
The Theme of an ArchitectureThe Purpose of an ArchitectureBut What About the Web?Frameworks Are Tools, Not Ways of LifeTestable ArchitecturesConclusion
The Dependency RuleA Typical ScenarioConclusion
The Humble Object PatternPresenters and ViewsTesting and ArchitectureDatabase GatewaysData MappersService ListenersConclusion
Skip the Last StepOne-Dimensional BoundariesFacadesConclusion
Hunt the WumpusClean Architecture?Crossing the StreamsSplitting the StreamsConclusion
The Ultimate DetailConclusion
Service Architecture?Service Benefits?The Kitty ProblemObjects to the RescueComponent-Based ServicesCross-Cutting ConcernsConclusion
Tests as System ComponentsDesign for TestabilityThe Testing APIConclusion
App-titude TestThe Target-Hardware BottleneckConclusion
Relational DatabasesWhy Are Database Systems So Prevalent?What If There Were No Disk?DetailsBut What about Performance?AnecdoteConclusion
The Endless PendulumThe UpshotConclusion
Framework AuthorsAsymmetric MarriageThe RisksThe SolutionI Now Pronounce You …Conclusion
The ProductUse Case AnalysisComponent ArchitectureDependency ManagementConclusion
Package by LayerPackage by FeaturePorts and AdaptersPackage by ComponentThe Devil Is in the Implementation DetailsOrganization versus EncapsulationOther Decoupling ModesConclusion: The Missing Advice

Content preview from Clean Architecture: A Craftsman's Guide to Software Structure and Design

29CLEAN EMBEDDED ARCHITECTURE

By James Grenning

A while ago I read an article entitled “The Growing Importance of Sustaining Software for the DoD”¹ on Doug Schmidt’s blog. Doug made the following claim:

“Although software does not wear out, firmware and hardware become obsolete, thereby requiring software modifications.”

It was a clarifying moment for me. Doug mentioned two terms that I would have thought to be obvious—but maybe not. Software is this thing that can have a long useful life, but firmware will become obsolete as hardware evolves. If you have spent any time in embedded systems development, you know the hardware is continually evolving ...