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

16INDEPENDENCE

As we previously stated, a good architecture must support:

• The use cases and operation of the system.

• The maintenance of the system.

• The development of the system.

• The deployment of the system.

USE CASES

The first bullet—use cases—means that the architecture of the system must support the intent of the system. If the system is a shopping cart application, then the architecture must support shopping cart use cases. Indeed, this is the first concern of the architect, and the first priority of the architecture. The architecture must support the use cases.

However, as we discussed previously, architecture does not wield much ...