内容简介

　　通过合理运用软件架构的通用法则，可以显著提升开发者在所有软件系统全生命周期内的生产力。如今，传奇软件匠师RobertC.Martin（Bob大叔），携畅销书CleanCode与TheCleanCoder所获巨大成功之威，深刻揭示这些法则并亲授运用之道。
　　Martin在《CleanArchitecture：软件架构与设计匠艺（英文版）》中远不只是在为我们提供选项，他几乎是在将软件世界中横跨半个世纪的各种架构类型的设计经验倾囊相授，目的是让读者既能阅尽所有架构选型，又可通晓其如何决定成败。Bob大叔也的确不负厚望，《CleanArchitecture：软件架构与设计匠艺（英文版）》中充满了直接而有效的解决方案，以供读者应对所面临的真正挑战——那些或最终成就或彻底破坏你项目的挑战。

作者简介

RobertCMartin(UncleBob)从1970年编程至今。他是cleancoders.com的联合创始人，该网站为软件开发者提供在线视频教育。同时，他还是UncldeBob咨询公司LLC的创始人，该公司为全球大型公司提供软件开发咨询服务、培训，以及技能培训服务。同时，他任8thLight,Inc的”首席匠人”一职，该公司是位于芝加哥的一家以加软件开发咨询公司。《Clean Architecture：软件架构与设计匠艺（英文版）》作者在各种行业周刊上出版了十余篇文章，同时也是国际会议和行业峰会经常邀请的演讲者。他曾任C++Report的主编三年，并且曾任敏捷联盟(AgileAliance)的主席。
RobertCMartin(UncleBob)从1970年编程至今。他是cleancoders.com的联合创始人，该网站为软件开发者提供在线视频教育。同时，他还是UncldeBob咨询公司LLC的创始人，该公司为全球大型公司提供软件开发咨询服务、培训，以及技能培训服务。同时，他任8thLight,Inc的”首席匠人”一职，该公司是位于芝加哥的一家以加软件开发咨询公司。《Clean Architecture：软件架构与设计匠艺（英文版）》作者在各种行业周刊上出版了十余篇文章，同时也是国际会议和行业峰会经常邀请的演讲者。他曾任C++Report的主编三年，并且曾任敏捷联盟(AgileAliance)的主席。

目录

PARTIIntroduction1
Chapter1WhatIsDesignandArchitecture?3
TheGoal?4
CaseStudy5
Conclusion12
Chapter2ATaleofTwoValues13
Behavior14
Architecture14
TheGreaterValue15
Eisenhower’sMatrix16
FightfortheArchitecture18
PARTIIStartingwiththeBricks：ProgrammingParadigms19
Chapter3ParadigmOverview21
StructuredProgramming22
Object-OrientedProgramming22
FunctionalProgramming22
FoodforThought23
Conclusion24
Chapter4StructuredProgramming25
Proof27
AHarmfulProclamation28
FunctionalDecomposition29
NoFormalProofs30
SciencetotheRescue30
Tests31
Conclusion31
Chapter5Object-OrientedProgramming33
Encapsulation?34
Inheritance?37
Polymorphism?40
Conclusion47
Chapter6FunctionalProgramming49
SquaresofIntegers50
ImmutabilityandArchitecture52
SegregationofMutability52
EventSourcing54
Conclusion56
PARTIIIDesignPrinciples57
Chapter7SRP：TheSingleResponsibilityPrinciple61
Symptom1：AccidentalDuplication63
Symptom2：Merges65
Solutions66
Conclusion67
Chapter8OCP：TheOpen-ClosedPrinciple69
AThoughtExperiment70
DirectionalControl74
InformationHiding74
Conclusion75
Chapter9LSP：TheLiskovSubstitutionPrinciple77
GuidingtheUseofInheritance78
TheSquare/RectangleProblem79
LSPandArchitecture80
ExampleLSPViolation80
Conclusion82
Chapter10ISP：TheInterfaceSegregationPrinciple83
ISPandLanguage85
ISPandArchitecture86
Conclusion86
Chapter11DIP：TheDependencyInversionPrinciple87
StableAbstractions88
Factories89
ConcreteComponents91
Conclusion91
PARTIVComponentPrinciples93
Chapter12Components95
ABriefHistoryofComponents96
Relocatability99
Linkers100
Conclusion102
Chapter13ComponentCohesion103
TheReuse/ReleaseEquivalencePrinciple104
TheCommonClosurePrinciple105
TheCommonReusePrinciple107
TheTensionDiagramforComponentCohesion108
Conclusion110
Chapter14ComponentCoupling111
TheAcyclicDependenciesPrinciple112
Top-DownDesign118
TheStableDependenciesPrinciple120
TheStableAbstractionsPrinciple126
Conclusion132
PARTVArchitecture133
Chapter15WhatIsArchitecture?135
Development137
Deployment138
Operation138
Maintenance139
KeepingOptionsOpen140
DeviceIndependence142
JunkMail144
PhysicalAddressing145
Conclusion146
Chapter16Independence147
UseCases148
Operation149
Development149
Deployment150
LeavingOptionsOpen150
DecouplingLayers151
DecouplingUseCases152
DecouplingMode153
IndependentDevelop-ability153
IndependentDeployability154
Duplication154
DecouplingModes(Again)155
Conclusion158
Chapter17Boundaries：DrawingLines159
ACoupleofSadStories160
FitNesse163
WhichLinesDoYouDraw，andWhenDoYouDrawThem?165
WhatAboutInputandOutput?169
PluginArchitecture170
ThePluginArgument172
Conclusion173
Chapter18BoundaryAnatomy175
BoundaryCrossing176
TheDreadedMonolith176
DeploymentComponents178
Threads179
LocalProcesses179
Services180
Conclusion181
Chapter19PolicyandLevel183
Level184
Conclusion187
Chapter20BusinessRules189
Entities190
UseCases191
RequestandResponseModels193
Conclusion194
Chapter21ScreamingArchitecture195
TheThemeofanArchitecture196
ThePurposeofanArchitecture197
ButWhatAbouttheWeb?197
FrameworksAreTools，NotWaysofLife198
TestableArchitectures198
Conclusion199
Chapter22TheCleanArchitecture201
TheDependencyRule203
ATypicalScenario207
Conclusion209
Chapter23PresentersandHumbleObjects211
TheHumbleObjectPattern212
PresentersandViews212
TestingandArchitecture213
DatabaseGateways214
DataMappers214
ServiceListeners215
Conclusion215
Chapter24PartialBoundaries217
SkiptheLastStep218
One-DimensionalBoundaries219
Facades220
Conclusion220
Chapter25LayersandBoundaries221
HunttheWumpus222
CleanArchitecture?223
CrossingtheStreams226
SplittingtheStreams227
Conclusion228
Chapter26TheMainComponent231
TheUltimateDetail232
Conclusion237
Chapter27Services：GreatandSmall239
ServiceArchitecture?240
ServiceBenefits?240
TheKittyProblem242
ObjectstotheRescue244
Component-BasedServices245
Cross-CuttingConcerns246
Conclusion247
Chapter28TheTestBoundary249
TestsasSystemComponents250
DesignforTestability251
TheTestingAPI252
Conclusion253
Chapter29CleanEmbeddedArchitecture255
App-titudeTest258
TheTarget-HardwareBottleneck261
Conclusion273
PARTVIDetails275
Chapter30TheDatabaseIsaDetail277
RelationalDatabases278
WhyAreDatabaseSystemsSoPrevalent?279
WhatIfThereWereNoDisk?280
Details281
ButWhataboutPerformance?281
Anecdote281
Conclusion283
Chapter31TheWebIsaDetail285
TheEndlessPendulum286
TheUpshot288
Conclusion289
Chapter32FrameworksAreDetails291
FrameworkAuthors292
AsymmetricMarriage292
TheRisks293
TheSolution294
INowPronounceYou…295
Conclusion295
Chapter33CaseStudy：VideoSales297
TheProduct298
UseCaseAnalysis298
ComponentArchitecture300
DependencyManagement302
Conclusion302
Chapter34TheMissingChapter303
PackagebyLayer304
PackagebyFeature306
PortsandAdapters308
PackagebyComponent310
TheDevilIsintheImplementationDetails315
OrganizationversusEncapsulation316
OtherDecouplingModes319
Conclusion：TheMissingAdvice321
PARTVIIAppendix323
AppendixAArchitectureArchaeology325
Index375

前言/序言

　　软件架构（Architecture）究竟指的是什么呢？
　　正向比喻是一种修辞手法，试图用架构的语言来描述某个软件，结果可粗可细，可能会过度描述，也可能会表达不足。
　　用架构来描述软件的明显优势是可以清晰地描绘其内在的组织结构（structure）。不管是在讨论组件、类、函数、模块（module）、还是层级、服务、微观与宏观的软件开发过程，组织结构都是一个主要关注点。但是真实世界中的许多软件项目并不是按我们的信念和理解生长的——它们底层层层嵌套，顶层则往往是一团乱麻，相互纠缠。有的时候真的很难让人相信，软件项目的组织结构性也能像物理建筑那样一目了然，层次清晰。
　　物理建筑，不管地基是石头还是水泥，高大还是宽阔，宏伟还是渺小，其组织结构都一目了然。物理建筑的组织结构必须被“重力”这个自然规律以及建筑材料自身的物理特性所约束。用砖头、水泥、木头、钢铁或者玻璃造就的物理建筑与软件项目相比，最大的不同点就是，大型软件项目由软件组件构成，而这些软件组件又由更小的软件组件构成，层层嵌套。
　　当我们讨论软件架构时，尤其要注意软件项目是具有递归（recursive）和分形（fractal）特点的，最终都要由一行行的代码组成。脱离了一行行的代码，脱离了具体的细节（detail）设计，架构问题就无从谈起。大型物理建筑的组织架构常常是由其中一个个细节设计共同决定的，如果细节设计太多，那么组织架构就会更复杂，反之亦然。但是软件项目的复杂程度却不一定能用物理尺度来衡量。软件项目也有组织结构，不论从数量上还是种类多样性上都远远超过物理建筑。我们可以很明确地说，软件开发比修建物理建筑需要更多、更专注的设计过程，软件架构师比建筑架构师更懂架构！

其他推荐