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

27SERVICES: GREAT AND SMALL

Service-oriented “architectures” and micro-service “architectures” have become very popular of late. The reasons for their current popularity include the following:

• Services seem to be strongly decoupled from each other. As we shall see, this is only partially true.

• Services appear to support independence of development and deployment. Again, as we shall see, this is only partially true.

SERVICE ARCHITECTURE?

First, let’s consider the notion that using services, by their nature, is an architecture. This is patently untrue. The architecture of a system is defined by boundaries that separate high-level policy from ...