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 человек отметили, что у них с чистой архитектурой всё чудесно складывается на практике, так что надежда получить позитивный опыт ещё жива😊
Когда я подняла тему чистой архитектуры, на меня посыпались рекомендации изучить книгу 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 человек отметили, что у них с чистой архитектурой всё чудесно складывается на практике, так что надежда получить позитивный опыт ещё жива😊
❤61👍28👎5