Алексей Oкружко - Чистая архитектура: Понять. Адаптировать. Использовать

[@senin24]

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

[@sergus82]

Спасибо за доклад! В одном из недавних проектов применяли данный подход (схожий процентов на 80-85, с некоторыми отличиями). Описанные преимущества действительно имеют место быть. На счёт упомянутого недостатка "более высокий порог входа в проект" (45:10). Говорилось, что нужен некий "onboarding" для новых сотрудников. Наверное объяснение "где что лежит" нужно для любой архитектуры. И, на мой взгляд, унифицированная структура и разделение на слои, как раз наоборот, помогали новым сотрудникам довольно быстро вливаться в проект.

[@conacry]

Спасибо! При активной разработке, используя DDD и Clean Arch, мы столкнулись с проблемой, что многие разработчики понимают концепции немного по разному, что приводило к вариациям в коде. Например: это логика usecase или можно все сделать в адаптерах. Поэтому мы утраивали несколько встреч, чтобы синхронизировать понимание. Также для новых разработчиков в начале сложно понять преимущества такого подхода. Мое понимание onboarding было связано именно с этим

[@ВладимирАкимов-х5х]

С терминологий большая беда, как в чистой архитектуре появились агрегаты и сервисы ? Это ведь одно и то же. То что создает вам инварианты между несколькими сущностями. Что вы там переименовывали и зачем не понятно, но это не страшно. Гейтвей у вас выступает в роли ДАО ? почему сервисы оказались на уровне Ентити ? потому что вы не правильно переименовали ?

[@nikitavashkulatov890]

Хороший доклад! Еще из практики я бы посоветовал Get your hands dirty with Clean Architecture. Можете подсказать где почитать лучше про event driven, как это здесь сделано. Заинтересовало

[@aleksey2793]

Окей, вдруг нам понадобилось масштабировать какую-то часть доменного слоя? Выделить в отдельный сервис. Что будем делать? Проще же было изначально разбить на доменные модули приложения, и для каждого из них сделать отдельные слои с портами, адаптерами. Разве нет?

[@AleksandrIlyin]

Подскажите как называется тема в IDEA, используемая в докладе)

[@rhino723]

Подарок, знает ребенка и проверяет его поведени ? Интересная логика из реального мира.

[@РусланУразбахтин-д2в]

Мне кажется, что первоначально было написано через ДДД'шныц агрегат, но позже решили упростить и убрать его. Хотя полностью согласен, в таком контексте выглядит не очень

[@smaginkv]

Спасибо за интересный доклад! А исходники будут?

[@JUGNsk]

Привет! Вот ссылка - github.com/conacry/santa-post-ca

[@ФилиппБондарев]

Почему подарок знает про ребёнка? Ещё и решает, какого размера ему быть в зависимости от поведения ребёнка?! Ничего не смущает? Дальше не смотрел.

[@valera924]

А что не так? Ну не ребёнку же решать, какого размера получать подарок

[@markhunt6499]

Предложи свой вариант, как должно было быть

[@sdsd-ec8rw]

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

[@markhunt6499]

Когда пишется код, можно следить за мыслью спикера. Когда он уже показывает кучу готового кода, это сложнее для зрителя. Надо изучить код, войти к контекст. Поэтому, лайвкодинг хороший вариант.

[@andreypozin8048]

Хуже этого доклада не видел за очень долгое время...просто отвратно донес идею Дяди Боба....лучше читать статьи с докладами в оригинале чем такое

[@markhunt6499]

Не поделишься ссылками, или своей версией реализации?

[@dzidzialis]

Это просто кашмар! Ребята найдите нормального архитектора. Меня просто порожает уровень докладчика.