Clean Architecture: A Craftsman's Guide to Software Structure and Design

Однажды Дейкстра сказал: «Тестирование показывает присутствие ошибок, а не их отсутствие». Иными словами, тестированием можно доказать неправильность программы, но нельзя доказать ее правильность. Все, что дает тестирование после приложения достаточных усилий, — это уверенность, что программа действует достаточно правильно.
​

Если вы думаете, что хорошая архитектура стоит дорого, попробуйте плохую архитектуру. // Брайан Фут и Джозеф Йодер

Факт отсутствия действующей базы данных в течение 18 месяцев разработки означал, что 18 месяцев мы не испытывали проблем со схемами, запросами, серверами баз данных, паролями, тайм-аутами и прочими неприятностями, которые непременно начинают проявляться, как только вы включаете в работу базу данных. Это также означало, что все наши тесты выполнялись очень быстро, потому что не было базы данных, тормозившей их.

Программные сущности должны быть открыты для расширения и закрыты для изменения.

Наука не требует доказательства истинности утверждений, чаще она требует доказательства их ложности. Утверждения, доказать ложность которых не удается после многих усилий, мы считаем истинными.

Разработчики и клиенты часто неправильно понимают, что такое система. Они видят графический интерфейс и думают, что он и есть система. Они определяют систему в терминах графического интерфейса и считают, что должны сразу начать работу с графическим интерфейсом. Они не понимают важнейшего принципа: ввод/вывод не важен.

Программирование — это нечто большее, чем умение писать работающие приложения.

У разработчиков программного обеспечения часто складывается ощущение, что их заставляют затыкать круглые отверстия квадратными пробками.

К цели ведет много путей.

Анализ прошлого сложен; понимание настоящего в лучшем случае переменчиво; предсказание будущего нетривиально.

заставить что-то работать - один раз - не очень сложно.

Первое правило проектирования программного обеспечения: не зависеть ни от чего, что может часто меняться.

Службы должны иметь компонентные архитектуры, следующие правила зависимостей.

Фреймворки - это инструменты, а не образ жизни.

Бизнес-правила - правила, делающие или экономящие деньги независимо от наличия или отсутствия их реализации на компьютере.

Принцип устойчивости абстракций гласит: Устойчивость компонента пропорциональна его абстрактности.

Не создавайте зависимостей от чего - либо неиспользуемого.

Принцип совместного повторного использования (CRP) гласит: не вынуждайте пользователей компонента зависеть от того, чего им не требуется.