3 Набор полезных и не очень, конкретных и абстрактных, актуальных и устаревших советов об архитектуре ПО

Главный недостаток книги — чрезмерная абстрактность и теоритизация. Большинство глав вообще без примеров, общими словами.

А значит каждый поймет как захочет => прикладная ценность существенно снижается.

И конечно фирменный отвратный перевод на русский. Вместо устоявшихся терминов "фича", "юзкейс" — особенность и случай использования. И т. п.

Но есть и ряд положительных инсайтов:

1. Хорошо показана идея направления зависимостей и изоляции между компонентами (всегда от низкоуровневых к высокоуровневым)
2. Показана роль архитектора, который должен найти этот баланс между идеальной изоляцией компонентов и простотой реализации. Для каждого конкретного случая.
3. Хорошо показано почему архитектурные границы системы не должны совпадать с инфраструктурными (отдельный микросервис != отдельный модуль). Нередко границы проходят по микросервисам и т. п.
4. Убедительно показано почему БД это деталь реализации и почему вредно вокруг нее строить бизне-модель приложения.
5. Надо отличать дублирование архитектуры от псевдодублирования (когда компоненты совпадают случайно и скорее всего будут развиваться независимо друг от друга). Агрессивно искоренять псевдодублирование на ранних этапах очень опасно (потом будет очень сложно раздублировать обратно).
6. Хороший архитектор как можно больше решений откладывает на потом (чем позже принимается конкретное архитектурное решение, например какую БД или формат файла использовать, тем больше информации для принятия хорошего решения).