Veze, linkovi
Kompjuter biblioteka
Korpa
Jasna arhitektura, Praktična rešenja softverske arhitekture legendarnog Roberta C. Martina,Ujka Boba

Tehnologija Tehnologija

Jasna arhitektura, Praktična rešenja softverske arhitekture legendarnog Roberta C. Martina,Ujka Boba

Autor: Robert C. Martin
Broj strana: 432
ISBN broj: 978-0-13-449416-6
Izdavač: PEARSON EDUCATION PEARSON EDUCATION
Godina izdanja: 2020.

Pregleda (30 dana / ukupno): 143 / 143

                 
Twitter   Facebook   Linkedin   Pinterest   Email
                 
Predlog za prevod

 

Features 

  • Practical answers to the most crucial questions software architects and designers face
  • How to choose the best high-level structures for each of today's diverse application types: from web to database, thick-client to console to embedded
  • Understanding the core principles of software architecture and design, and what you're really trying to achieve
  • By the renowned Robert C. Martin, author of The Clean Coder, Clean Code, and Agile Software Development: Principles, Patterns, and Practices

Practical Software Architecture Solutions from the Legendary Robert C. Martin (“Uncle Bob”)

By applying universal rules of software architecture, you can dramatically improve developer productivity throughout the life of any software system. Now, building upon the success of his best-selling books Clean Code and The Clean Coder, legendary software craftsman Robert C. Martin (“Uncle Bob”) reveals those rules and helps you apply them.

Martin’s Clean Architecture doesn’t merely present options. Drawing on over a half-century of experience in software environments of every imaginable type, Martin tells you what choices to make and why they are critical to your success. As you’ve come to expect from Uncle Bob, this book is packed with direct, no-nonsense solutions for the real challenges you’ll face–the ones that will make or break your projects.

  • Learn what software architects need to achieve–and core disciplines and practices for achieving it
  • Master essential software design principles for addressing function, component separation, and data management
  • See how programming paradigms impose discipline by restricting what developers can do
  • Understand what’s critically important and what’s merely a “detail”
  • Implement optimal, high-level structures for web, database, thick-client, console, and embedded applications
  • Define appropriate boundaries and layers, and organize components and services
  • See why designs and architectures go wrong, and how to prevent (or fix) these failures

Clean Architecture is essential reading for every current or aspiring software architect, systems analyst, system designer, and software manager–and for every programmer who must execute someone else’s designs.

Author's Site

Please visit the author's site at https://cleancoders.com/.

Table of Contents

Foreword xv

Preface xix

Acknowledgments xxiii

About the Author xxv

Part I: Introduction 1

Chapter 1: What Is Design and Architecture? 3

The Goal? 4

Case Study 5

Conclusion 12

Chapter 2: A Tale of Two Values 13

  • Behavior 14
  • Architecture 14
  • The Greater Value 15
  • Eisenhower’s Matrix 16
  • Fight for the Architecture 18
  • Part II: Starting with the Bricks: Programming Paradigms 19

Chapter 3: Paradigm Overview 21

  • Structured Programming 22
  • Object-Oriented Programming 22
  • Functional Programming 22
  • Food for Thought 23
  • Conclusion 24

Chapter 4: Structured Programming 25

  • Proof 27
  • A Harmful Proclamation 28
  • Functional Decomposition 29
  • No Formal Proofs 30
  • Science to the Rescue 30
  • Tests 31
  • Conclusion 31

Chapter 5: Object-Oriented Programming 33

  • Encapsulation? 34
  • Inheritance? 37
  • Polymorphism? 40
  • Conclusion 47

Chapter 6: Functional Programming 49

  • Squares of Integers 50
  • Immutability and Architecture 52
  • Segregation of Mutability 52
  • Event Sourcing 54
  • Conclusion 56
  • Part III: Design Principles 57
  • Chapter 7: SRP: The Single Responsibility Principle 61
  • Symptom 1: Accidental Duplication 63
  • Symptom 2: Merges 65
  • Solutions 66
  • Conclusion 67

Chapter 8: OCP: The Open-Closed Principle 69

  • A Thought Experiment 70
  • Directional Control 74
  • Information Hiding 74
  • Conclusion 75

Chapter 9: LSP: The Liskov Substitution Principle 77

  • Guiding the Use of Inheritance 78
  • The Square/Rectangle Problem 79
  • LSP and Architecture 80
  • Example LSP Violation 80
  • Conclusion 82

Chapter 10: ISP: The Interface Segregation Principle 83

  • ISP and Language 85
  • ISP and Architecture 86
  • Conclusion 86

Chapter 11: DIP: The Dependency Inversion Principle 87

  • Stable Abstractions 88
  • Factories 89
  • Concrete Components 91
  • Conclusion 91
  • Part IV: Component Principles 93
  • Chapter 12: Components 95
  • A Brief History of Components 96
  • Relocatability 99
  • Linkers 100
  • Conclusion 102

Chapter 13: Component Cohesion 103

  • The Reuse/Release Equivalence Principle 104
  • The Common Closure Principle 105
  • The Common Reuse Principle 107
  • The Tension Diagram for Component Cohesion 108
  • Conclusion 110

Chapter 14: Component Coupling 111

  • The Acyclic Dependencies Principle 112
  • Top-Down Design 118
  • The Stable Dependencies Principle 120
  • The Stable Abstractions Principle 126
  • Conclusion 132
  • Part V: Architecture 133
  • Chapter 15: What Is Architecture? 135
  • Development 137
  • Deployment 138
  • Operation 138
  • Maintenance 139
  • Keeping Options Open 140
  • Device Independence 142
  • Junk Mail 144
  • Physical Addressing 145
  • Conclusion 146

Chapter 16: Independence 147

  • Use Cases 148
  • Operation 149
  • Development 149
  • Deployment 150
  • Leaving Options Open 150
  • Decoupling Layers 151
  • Decoupling Use Cases 152
  • Decoupling Mode 153
  • Independent Develop-ability 153
  • Independent Deployability 154
  • Duplication 154
  • Decoupling Modes (Again) 155
  • Conclusion 158

Chapter 17: Boundaries: Drawing Lines 159

  • A Couple of Sad Stories 160
  • FitNesse 163
  • Which Lines Do You Draw, and When Do You Draw Them? 165
  • What About Input and Output? 169
  • Plugin Architecture 170
  • The Plugin Argument 172
  • Conclusion 173

Chapter 18: Boundary Anatomy 175

  • Boundary Crossing 176
  • The Dreaded Monolith 176
  • Deployment Components 178
  • Threads 179
  • Local Processes 179
  • Services 180
  • Conclusion 181

Chapter 19: Policy and Level 183

  • Level 184
  • Conclusion 187

Chapter 20: Business Rules 189

  • Entities 190
  • Use Cases 191
  • Request and Response Models 193
  • Conclusion 194

Chapter 21: Screaming Architecture 195

  • The Theme of an Architecture 196
  • The Purpose of an Architecture 197
  • But What About the Web? 197
  • Frameworks Are Tools, Not Ways of Life 198
  • Testable Architectures 198
  • Conclusion 199

Chapter 22: The Clean Architecture 201

  • The Dependency Rule 203
  • A Typical Scenario 207
  • Conclusion 209

Chapter 23: Presenters and Humble Objects 211

  • The Humble Object Pattern 212
  • Presenters and Views 212
  • Testing and Architecture 213
  • Database Gateways 214
  • Data Mappers 214
  • Service Listeners 215
  • Conclusion 215

Chapter 24: Partial Boundaries 217

  • Skip the Last Step 218
  • One-Dimensional Boundaries 219
  • Facades 220
  • Conclusion 220

Chapter 25: Layers and Boundaries 221

  • Hunt the Wumpus 222
  • Clean Architecture? 223
  • Crossing the Streams 226
  • Splitting the Streams 227
  • Conclusion 228

Chapter 26: The Main Component 231

  • The Ultimate Detail 232
  • Conclusion 237

Chapter 27: Services: Great and Small 239

  • Service Architecture? 240
  • Service Benefits? 240
  • The Kitty Problem 242
  • Objects to the Rescue 244
  • Component-Based Services 245
  • Cross-Cutting Concerns 246
  • Conclusion 247

Chapter 28: The Test Boundary 249

  • Tests as System Components 250
  • Design for Testability 251
  • The Testing API 252
  • Conclusion 253

Chapter 29: Clean Embedded Architecture 255

  • App-titude Test 258
  • The Target-Hardware Bottleneck 261
  • Conclusion 273
  • Part VI: Details 275
  • Chapter 30: The Database Is a Detail 277
  • Relational Databases 278
  • Why Are Database Systems So Prevalent? 279
  • What If There Were No Disk? 280
  • Details 281
  • But What about Performance? 281
  • Anecdote 281
  • Conclusion 283

Chapter 31: The Web Is a Detail 285

  • The Endless Pendulum 286
  • The Upshot 288
  • Conclusion 289

Chapter 32: Frameworks Are Details 291

  • Framework Authors 292
  • Asymmetric Marriage 292
  • The Risks 293
  • The Solution 294
  • I Now Pronounce You … 295
  • Conclusion 295

Chapter 33: Case Study: Video Sales 297

  • The Product 298
  • Use Case Analysis 298
  • Component Architecture 300
  • Dependency Management 302
  • Conclusion 302

Chapter 34: The Missing Chapter 303

  • Package by Layer 304
  • Package by Feature 306
  • Ports and Adapters 308
  • Package by Component 310
  • The Devil Is in the Implementation Details 315
  • Organization versus Encapsulation 316
  • Other Decoupling Modes 319
  • Conclusion: The Missing Advice 321

Part VII: Appendix 323

Appendix A Architecture Archaeology 325

Index 375

 

Komentari

• Vladimir Šimunić
Podržavam kvalitetan i inteligentan prevod ove knjige. Zato što se ovde radi o strateškim stvarima, koje traju dugo a ne samo od danas do sutra. Po mom mišljenju za prevođenje ovakvog teksta potrebna je pomoć od strane profesionalnih softverskih inženjera i arhitekata koji dobro i iz prakse tj. iznutra razumeju problematiku koju knjiga obrađuje. Kao izdavač ne bih žalio novca i vremena za dobre konsultante za prevod jer mi se kao kupcu isplati da kupim skuplju knjigu ali samo ako znam da je dobro, kvalitetno i pametno prevedena. Sa druge strane ako se ovako stručna knjiga loše prevede onda mi je i postojeća engleska verzija dovoljno dobra. Takođe mislim da bi prevodilac (ili prevodioci) trebalo da bude dovoljno pametan da u zagradama ili makar u fusnotama ostavi sve stručno-ključne engleske nazive iz originala.

• Lazar
Preporuka za knjigu

• Milos
Odlicna.

• Uglješa Pupavac
Ovo je odlicna knjiga. Trebalo bi da je procita svaki ozbiljan developer. Preporuka za prevod!

• Dragan
Ovo morate izbaciti. Uncle Bob ili Robert C. Martin je bukvalno kralj sto se tice pisanje dobrog koda. Lik je smislio SOLID principe. Ovo je must knjiga za svakog programera.

Ostavite komentar Ostavite komentar

 

Preporučujemo

Biodizel, biogas, biomasa

Biodizel, biogas, biomasa

Unit Testing Principles, Practices, and Patterns

Unit Testing Principles, Practices, and Patterns

Veze, linkovi
Linkedin Twitter Facebook
 
     
 
© Sva prava pridržana, Kompjuter biblioteka, Beograd, Obalskih radnika 4a, Telefon: +381 11 252 0 272