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

30THE DATABASE IS A DETAIL

From an architectural point of view, the database is a non-entity—it is a detail that does not rise to the level of an architectural element. Its relationship to the architecture of a software system is rather like the relationship of a doorknob to the architecture of your home.

I realize that these are fighting words. Believe me, I’ve had the fight. So let me be clear: I am not talking about the data model. The structure you give to the data within your application is highly significant to the architecture of your system. But the database is not the data model. The database is piece of software. The database is a utility ...