Java: fill the gaps

Get Your Hands Dirty on Clean Architecture: отзыв на книгу Когда я подняла тему чистой архитектуры, на меня посыпались рекомендации изучить книгу Get Your Hands Dirty on Clean Architecture, автор Tom Hombergs. Прочитала, делюсь отзывом! Сердце книги — сервис перевода денег с одним методом. Этот сервис автор реализует в гексагональной архитектуре (она же "порты и адаптеры"), подробно объясняя каждый шаг и возможные варианты. Получается приятный баланс теории и практики. В книге чуть больше 100 страниц, много схем и кода на джаве, читается быстро. Варианта на русском нет, но язык очень простой. Помимо реализации сервиса, поднимаются такие темы (в скобках укажу позицию автора): ▫️ Чем плоха слоистая архитектура Controller-Service-Repository (всё опирается на структуру БД, код в сервисах становится сильно связанным месивом) ▫️ Как связаны чистая и гексагональная архитектуры (чистая более абстракна, гексагональная - вариация с портами и адаптерами) ▫️ Виды валидации (техническая валидация и уровне бизнес правил) ▫️ Где открывать и закрывать транзакции (в use case) ▫️ Какие тесты и для чего писать (юниты для бизнес логики, интеграционные для контроллеров и репозиториев + сквозной тест для основных сценариев ▫️ Как соблюдать границы слоев по мере развития проекта (модификаторы доступа, ArchUnit, Maven/Gradle модули) ▫️ Можно ли упрощать архитектуру? Пропускать слои, использовать доменные сущности в контроллерах? (зависит от сложности сервиса и договоренностей внутри команды) ▫️ Для каких проектов подойдёт чистая архитектура? (со сложной доменной логикой) Основные минусы книги: 1️⃣ Неподходящий формат Обсуждать код даже маленького сервиса очень неудобно в рамках книги. Приходится прыгать по страницам, чтобы понять, что откуда вызывается и зачем. Чтобы просто посмотреть чистую архитектуру на практике, лучше глянуть код проекта на гитхабе. 2️⃣ Сомнительный use-case В проекте заявлен всего один use-case, и в книге даже нет реализации. Есть разные способы распределить код между доменом, сценарием и application слоем. На примере перевода денег можно показать разные подходы. Но этого нет. Сложилось впечатление, что книга больше о структуре проекта, как раскидать код по классам. Разделение логики на бизнес-правила и инфраструктуру — киллер-фича чистой архитектуры, а тут она задвинута на десятый план. ⭐️ Общая оценка: 3/5 ⭐️ Для кого: для тех, кто только знакомится с чистой/гексагональной архитектурой. Кто увидел схему с кружочками и задумался "а как при этом выглядит проект". Задачу знакомства книга решает отлично, но написать что-то серьёзное на этой базе вряд ли получится. На этом арка изучения Clean architecture пока заканчивается. Надеюсь однажды попасть на проект с чистой архитектурой, который функционирует больше года и не превратился в гору мусора. Думаю, тогда многое встанет на свои места. 96 человек отметили, что у них с чистой архитектурой всё чудесно складывается на практике, так что надежда получить позитивный опыт ещё жива😊