دانش و مهارت زیادی لازم نیست تا یک برنامه نوشت. بچه‌های دبیرستانی نیز این کار را در دبیرستان انجام می‌دهند. مردان و زنان جوان در دانشگاه با سر هم کردن چند خط کد PHP یا Ruby کسب و کار‌های میلیارد دلاری را شروع کرده اند. برنامه نویسان تازه کار زیادی در دفاتر کاری مکعبی شکلشان در سرتاسر دنیا در بین اسناد حجیم نیازمندی‌های موجود در سیستم‌های issue tracking خود در حال تقلا هستند تا سیستم هایشان را با صرف فعل خواستن توانستن است به کار بیندازند. کدهایی که تولید می‌کنند ممکن است زیبا نباشند ولی کار می‌کنند. کار می‌کند به این دلیل که چیزی بتواند یک بار کار کند، خیلی سخت هم نیست.
این که چیزی واقعا به درستی کار کند موضوعی کاملا متفاوت است. پیاده سازی صحیح نرم افزار سخت است چرا که دانش و مهارت هایی نیاز دارد که هنوز بیشتر برنامه نویسان جوان به آن دست نیافته اند. این کار به بینش و تفکری احتیاج دارد که بیشتر برنامه نویسان وقتی برای توسعه آن‌ها نمی‌گذارند. همه‌ی این‌ها به سطحی از انضباط و تعهد احتیاج دارد که بسیاری از برنامه نویسان حتی خوابش را نمی‌دیدند که به آن‌ها احتیاج پیدا کنند و در بیشتر موارد اشتیاق به مهارت و تمایل به حرفه ای شدن است.
وقتی که برنامه را به شکل صحیح پیاده سازی کنید، چیزی جادویی اتفاق می‌افتد: دیگر به لشکری از برنامه نویسان برای این که آن را در حال کار کردن نگه دارند نیاز ندارید. دیگر به سندهای نیازمندی‌های حجیم و سیستم‌های issue tracking بزرگ احتیاج ندارید. شما دیگر به اتاق‌های کاری مکعبی شکل زیاد و برنامه نویسی 24 ساعت و هفت روز در هفته نیاز ندارید.
نرم افزاری که یه شکل صحیح تمام شود، تعداد کمتری از منابع انسانی برای ایجاد و نگه داری نیاز دارد. تغییرات به سرعت و ساده هستند. نقص‌ها کم و فاصله‌ی بین آن‌ها کم است. تلاش کاهش می‌یاد، عملکرد و انعطاف پذیری افزایش می‌یابد.
بله، همچین چشم اندازی به نظر خیال پردازی می‌آید. ولی من آن جا بوده ام، من دیدم که اتفاق افتاد. من بر روی پروژه هایی کار کرده ام که طراحی و معماری سیستم، نوشتن کد و نگهداری آن را آسان کرده بود. پروژه هایی را تجربه کرده ام که به کسری از نیرو‌های انسانی پیش پینی شده احتیاج پیدا کرده بود. بر روی سیستم هایی کار کرده ام که نرخ نقص به شدت پایینی داشته اند. من تاثیرات خارق العاده ای که یک معماری نرم افزاری خوب می‌تواند بر روی سیستم، پروژه و تیم داشته باشد را دیده ام.
اما حرف‌های من را در نظر نگیرید. به تجربه خودتان نگاه کنید. آیا خلافش را تجربه کرده اید؟ آیا بر روی سیستم هایی کار کرده اید که جوری به هم پیوسته و پیچیده اند که هر تغییری جدای از این که چقدر واضح و ساده باشد، هفته‌ها طول می‌کشد و خطر‌های بزرگی را شامل می‌شود. آیا طراحی سیستم هایی که با آن‌ها کار کرده اید تاثیر منفی بزرگی بر روی روحیه تیم، اعتماد مشتریان، سازمان‌ها و حوصله‌ی مدیران گذاشته اند؟ آیا تیم ها، سازمان‌ها و حتی شرکت هایی که به وسیله‌ی ساختار نرم افزاری فاسد خود نابود شده اند را دیده اید؟ آیا تا به حال در جهنم برنامه نویسان بوده اید؟
من بوده ام و تا حدودی بیشتر ما نیز بوده ایم. تفاوت بسیار زیادی است بین وقتی که شما دارید با طراحی‌های نرم افزاری افتضاح کلنجار می‌روید تا وقتی که دارید از کار با یکی از طراحی‌های خوب لذت می‌برید.

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.

Register your product at informit.com/register for convenient access to downloads, updates, and/or corrections as they become available.

Table of Contents
PART I Introduction
Chapter 1 What Is Design and Architecture?
Chapter 2 A Tale of Two Values

PART II Starting with the Bricks: Programming Paradigms
Chapter 3 Paradigm Overview
Chapter 4 Structured Programming
Chapter 5 Object-Oriented Programming
Chapter 6 Functional Programming

PART III Design Principles
Chapter 7 SRP: The Single Responsibility Principle
Chapter 8 OCP: The Open-Closed Principle
Chapter 9 LSP: The Liskov Substitution Principle
Chapter 10 ISP: The Interface Segregation Principle
Chapter 11 DIP: The Dependency Inversion Principle

PART IV Component Principles
Chapter 12 Components
Chapter 13 Component Cohesion
Chapter 14 Component Coupling

PART V Architecture
Chapter 15 What Is Architecture?
Chapter 16 Independence
Chapter 17 Boundaries: Drawing Lines
Chapter 18 Boundary Anatomy
Chapter 19 Policy and Level
Chapter 20 Business Rules
Chapter 21 Screaming Architecture
Chapter 22 The Clean Architecture
Chapter 23 Presenters and Humble Objects
Chapter 24 Partial Boundaries
Chapter 25 Layers and Boundaries
Chapter 26 The Main Component
Chapter 27 Services: Great and Small
Chapter 28 The Test Boundary
Chapter 29 Clean Embedded Architecture

PART VI Details
Chapter 30 The Database Is a Detail
Chapter 31 The Web Is a Detail
Chapter 32 Frameworks Are Details
Chapter 33 Case Study: Video Sales
Chapter 34 The Missing Chapter

PART VII Appendix
Appendix A Architecture Archaeology