Muutke küpsiste eelistusi

Clean Architecture: A Craftsman's Guide to Software Structure and Design [Pehme köide]

4.22/5 (12294 hinnangut Goodreads-ist)
  • Formaat: Paperback / softback, 432 pages, kõrgus x laius x paksus: 231x175x23 mm, kaal: 740 g
  • Sari: Robert C. Martin Series
  • Ilmumisaeg: 20-Sep-2017
  • Kirjastus: Pearson
  • ISBN-10: 0134494164
  • ISBN-13: 9780134494166
Teised raamatud teemal:
Clean Architecture: A Craftsman's Guide to Software Structure and DesignSuurem pilt
  • Formaat: Paperback / softback, 432 pages, kõrgus x laius x paksus: 231x175x23 mm, kaal: 740 g
  • Sari: Robert C. Martin Series
  • Ilmumisaeg: 20-Sep-2017
  • Kirjastus: Pearson
  • ISBN-10: 0134494164
  • ISBN-13: 9780134494166
Teised raamatud teemal:
Püsilink: https://www.kriso.ee/db/9780134494166.html
Märksõnad:

Building upon the success of best-sellers The Clean Coder and Clean Code, legendary software craftsman Robert C. "Uncle Bob" Martin shows how to bring greater professionalism and discipline to application architecture and design.

 

As with his other books, Martin's Clean Architecture doesn't merely present multiple choices and options, and say "use your best judgment": it tells you what choices to make, and why those choices are critical to your success. Martin offers direct, no-nonsense answers to key architecture and design questions like:

  • What are the best high level structures for different kinds of applications, including web, database, thick-client, console, and embedded apps?
  • What are the core principles of software architecture?
  • What is the role of the architect, and what is he/she really trying to achieve?
  • What are the core principles of software design?
  • How do designs and architectures go wrong, and what can you do about it?
  • What are the disciplines and practices of professional architects and designers?

Clean Architecture is essential reading for every software architect, systems analyst, system designer, and software manager -- and for any programmer who aspires to these roles or is impacted by their work.

Foreword xv
Preface xix
Acknowledgments xxiii
About the Author xxv
Part I Introduction
Chapter 1 What Is Design and Architecture?
3(10)
The Goal?
4(1)
Case Study
5(7)
Conclusion
12(1)
Chapter 2 A Tale of Two Values
13(6)
Behavior
14(1)
Architecture
14(1)
The Greater Value
15(1)
Eisenhower's Matrix
16(2)
Fight for the Architecture
18(1)
Part II Starting with the Bricks: Programming Paradigms 19(38)
Chapter 3 Paradigm Overview
21(4)
Structured Programming
22(1)
Object-Oriented Programming
22(1)
Functional Programming
22(1)
Food for Thought
23(1)
Conclusion
24(1)
Chapter 4 Structured Programming
25(8)
Proof
27(1)
A Harmful Proclamation
28(1)
Functional Decomposition
29(1)
No Formal Proofs
30(1)
Science to the Rescue
30(1)
Tests
31(1)
Conclusion
31(2)
Chapter 5 Object-Oriented Programming
33(16)
Encapsulation?
34(3)
Inheritance?
37(3)
Polymorphism?
40(7)
Conclusion
47(2)
Chapter 6 Functional Programming
49(8)
Squares of Integers
50(2)
Immutability and Architecture
52(1)
Segregation of Mutability
52(2)
Event Sourcing
54(2)
Conclusion
56(1)
Part III Design Principles 57(36)
Chapter 7 SRP: The Single Responsibility Principle
61(8)
Symptom 1: Accidental Duplication
63(2)
Symptom 2: Merges
65(1)
Solutions
66(1)
Conclusion
67(2)
Chapter 8 OCP: The Open-Closed Principle
69(8)
A Thought Experiment
70(4)
Directional Control
74(1)
Information Hiding
74(1)
Conclusion
75(2)
Chapter 9 LSP: The Liskov Substitution Principle
77(6)
Guiding the Use of Inheritance
78(1)
The Square/Rectangle Problem
79(1)
LSP and Architecture
80(1)
Example LSP Violation
80(2)
Conclusion
82(1)
Chapter 10 ISP: The Interface Segregation Principle
83(4)
ISP and Language
85(1)
ISP and Architecture
86(1)
Conclusion
86(1)
Chapter 11 DIP: The Dependency Inversion Principle
87(6)
Stable Abstractions
88(1)
Factories
89(2)
Concrete Components
91(1)
Conclusion
91(2)
Part IV Component Principles 93(40)
Chapter 12 Components
95(8)
A Brief History of Components
96(3)
Relocatability
99(1)
Linkers
100(2)
Conclusion
102(1)
Chapter 13 Component Cohesion
103(9)
The Reuse/Release Equivalence Principle
104(1)
The Common Closure Principle
105(2)
The Common Reuse Principle
107(1)
The Tension Diagram for Component Cohesion
108(2)
Conclusion
110(2)
Chapter 14 Component Coupling
The Acyclic Dependencies Principle
112(6)
Top-Down Design
118(2)
The Stable Dependencies Principle
120(6)
The Stable Abstractions Principle
126(6)
Conclusion
132(1)
Part V Architecture 133(142)
Chapter 15 What Is Architecture?
135(12)
Development
137(1)
Deployment
138(1)
Operation
138(1)
Maintenance
139(1)
Keeping Options Open
140(2)
Device Independence
142(2)
Junk Mail
144(1)
Physical Addressing
145(1)
Conclusion
146(1)
Chapter 16 Independence
147(12)
Use Cases
148(1)
Operation
149(1)
Development
149(1)
Deployment
150(1)
Leaving Options Open
150(1)
Decoupling Layers
151(1)
Decoupling Use Cases
152(1)
Decoupling Mode
153(1)
Independent Develop-ability
153(1)
Independent Deployability
154(1)
Duplication
154(1)
Decoupling Modes (Again)
155(3)
Conclusion
158(1)
Chapter 17 Boundaries: Drawing Lines
159(16)
A Couple of Sad Stories
160(3)
FitNesse
163(2)
Which Lines Do You Draw, and When Do You Draw Them?
165(4)
What About Input and Output?
169(1)
Plugin Architecture
170(2)
The Plugin Argument
172(1)
Conclusion
173(2)
Chapter 18 Boundary Anatomy
175(8)
Boundary Crossing
176(1)
The Dreaded Monolith
176(2)
Deployment Components
178(1)
Threads
179(1)
Local Processes
179(1)
Services
180(1)
Conclusion
181(2)
Chapter 19 Policy and Level
183(6)
Level
184(3)
Conclusion
187(2)
Chapter 20 Business Rules
189(6)
Entities
190(1)
Use Cases
191(2)
Request and Response Models
193(1)
Conclusion
194(1)
Chapter 21 Screaming Architecture
195(6)
The Theme of an Architecture
196(1)
The Purpose of an Architecture
197(1)
But What About the Web?
197(1)
Frameworks Are Tools, Not Ways of Life
198(1)
Testable Architectures
198(1)
Conclusion
199(2)
Chapter 22 The Clean Architecture
201(10)
The Dependency Rule
203(4)
A Typical Scenario
207(2)
Conclusion
209(2)
Chapter 23 Presenters and Humble Objects
211(6)
The Humble Object Pattern
212(1)
Presenters and Views
212(1)
Testing and Architecture
213(1)
Database Gateways
214(1)
Data Mappers
214(1)
Service Listeners
215(1)
Conclusion
215(2)
Chapter 24 Partial Boundaries
217(4)
Skip the Last Step
218(1)
One-Dimensional Boundaries
219(1)
Facades
220(1)
Conclusion
220(1)
Chapter 25 Layers and Boundaries
221(10)
Hunt the Wumpus
222(1)
Clean Architecture?
223(3)
Crossing the Streams
226(1)
Splitting the Streams
227(1)
Conclusion
228(3)
Chapter 26 The Main Component
231(8)
The Ultimate Detail
232(5)
Conclusion
237(2)
Chapter 27 Services: Great and Small
239(10)
Service Architecture?
240(1)
Service Benefits?
240(2)
The Kitty Problem
242(2)
Objects to the Rescue
244(1)
Component-Based Services
245(1)
Cross-Cutting Concerns
246(1)
Conclusion
247(2)
Chapter 28 The Test Boundary
249(6)
Tests as System Components
250(1)
Design for Testability
251(1)
The Testing API
252(1)
Conclusion
253(2)
Chapter 29 Clean Embedded Architecture
255(20)
App-titude Test
258(3)
The Target-Hardware Bottleneck
261(12)
Conclusion
273(2)
Part VI Details 275(48)
Chapter 30 The Database Is a Detail
277(8)
Relational Databases
278(1)
Why Are Database Systems So Prevalent?
279(1)
What If There Were No Disk?
280(1)
Details
281(1)
But What about Performance?
281(1)
Anecdote
281(2)
Conclusion
283(2)
Chapter 31 The Web Is a Detail
285(6)
The Endless Pendulum
286(2)
The Upshot
288(1)
Conclusion
289(2)
Chapter 32 Frameworks Are Details
291(6)
Framework Authors
292(1)
Asymmetric Marriage
292(1)
The Risks
293(1)
The Solution
294(1)
I Now Pronounce You...
295(1)
Conclusion
295(2)
Chapter 33 Case Study: Video Sales
297(6)
The Product
298(1)
Use Case Analysis
298(2)
Component Architecture
300(2)
Dependency Management
302(1)
Conclusion
302(1)
Chapter 34 The Missing
Chapter
303(20)
Package by Layer
304(2)
Package by Feature
306(2)
Ports and Adapters
308(2)
Package by Component
310(5)
The Devil Is in the Implementation Details
315(1)
Organization versus Encapsulation
316(3)
Other Decoupling Modes
319(2)
Conclusion: The Missing Advice
321(2)
Part VII Appendix 323(52)
Appendix A Architecture Archaeology
325(50)
Index 375
Robert C. Martin (Uncle Bob) has been a programmer since 1970. He is founder of Uncle Bob Consulting, LLC, and cofounder with his son Micah Martin of The Clean Coders LLC. Martin has published dozens of articles in various trade journals and is a regular speaker at international conferences and trade shows. He has authored and edited many books, including: Designing Object Oriented C++ Applications Using the Booch Method, Patterns Languages of Program Design 3, More C++ Gems, Extreme Programming in Practice, Agile Software Development: Principles, Patterns, and Practices, UML for Java Programmers, Clean Code, and The Clean Coder. A leader in the industry of software development, Martin served for three years as editor-in-chief of the C++ Report, and he served as the first chairman of the Agile Alliance.