С терминологий большая беда, как в чистой архитектуре появились агрегаты и сервисы ? Это ведь одно и то же. То что создает вам инварианты между несколькими сущностями. Что вы там переименовывали и зачем не понятно, но это не страшно. Гейтвей у вас выступает в роли ДАО ? почему сервисы оказались на уровне Ентити ? потому что вы не правильно переименовали ?
Спасибо за доклад! В одном из недавних проектов применяли данный подход (схожий процентов на 80-85, с некоторыми отличиями). Описанные преимущества действительно имеют место быть. На счёт упомянутого недостатка "более высокий порог входа в проект" (45:10). Говорилось, что нужен некий "onboarding" для новых сотрудников. Наверное объяснение "где что лежит" нужно для любой архитектуры. И, на мой взгляд, унифицированная структура и разделение на слои, как раз наоборот, помогали новым сотрудникам довольно быстро вливаться в проект.
Спасибо! При активной разработке, используя DDD и Clean Arch, мы столкнулись с проблемой, что многие разработчики понимают концепции немного по разному, что приводило к вариациям в коде. Например: это логика usecase или можно все сделать в адаптерах. Поэтому мы утраивали несколько встреч, чтобы синхронизировать понимание. Также для новых разработчиков в начале сложно понять преимущества такого подхода. Мое понимание onboarding было связано именно с этим
Полезная и сложная тема, которая требует от слушателей не только напряжения внимания, но и достаточного опыта в энтерпрайз разработке приложений с запутанной бизнес-логикой. И горьким личным опытом как относительно простые и понятные приложения с течением времени превращаются в комок грязи, если в архитектуре кода не была предусмотрена изоляция слоев.
Хороший доклад! Еще из практики я бы посоветовал Get your hands dirty with Clean Architecture. Можете подсказать где почитать лучше про event driven, как это здесь сделано. Заинтересовало
Окей, вдруг нам понадобилось масштабировать какую-то часть доменного слоя? Выделить в отдельный сервис. Что будем делать? Проще же было изначально разбить на доменные модули приложения, и для каждого из них сделать отдельные слои с портами, адаптерами. Разве нет?
Мне кажется, что первоначально было написано через ДДД'шныц агрегат, но позже решили упростить и убрать его. Хотя полностью согласен, в таком контексте выглядит не очень
))) сопит как паровоз, когда зачем-то пишет код, хотя у самого уже готовый проект имеется, можно спокойно показывать и рассказывать. Но парень, видно, не ищет легких путей))
Когда пишется код, можно следить за мыслью спикера. Когда он уже показывает кучу готового кода, это сложнее для зрителя. Надо изучить код, войти к контекст. Поэтому, лайвкодинг хороший вариант.
С терминологий большая беда, как в чистой архитектуре появились агрегаты и сервисы ? Это ведь одно и то же. То что создает вам инварианты между несколькими сущностями.
Что вы там переименовывали и зачем не понятно, но это не страшно. Гейтвей у вас выступает в роли ДАО ? почему сервисы оказались на уровне Ентити ? потому что вы не правильно переименовали ?
Спасибо за доклад!
В одном из недавних проектов применяли данный подход (схожий процентов на 80-85, с некоторыми отличиями). Описанные преимущества действительно имеют место быть.
На счёт упомянутого недостатка "более высокий порог входа в проект" (45:10). Говорилось, что нужен некий "onboarding" для новых сотрудников. Наверное объяснение "где что лежит" нужно для любой архитектуры. И, на мой взгляд, унифицированная структура и разделение на слои, как раз наоборот, помогали новым сотрудникам довольно быстро вливаться в проект.
Спасибо! При активной разработке, используя DDD и Clean Arch, мы столкнулись с проблемой, что многие разработчики понимают концепции немного по разному, что приводило к вариациям в коде. Например: это логика usecase или можно все сделать в адаптерах. Поэтому мы утраивали несколько встреч, чтобы синхронизировать понимание. Также для новых разработчиков в начале сложно понять преимущества такого подхода. Мое понимание onboarding было связано именно с этим
Полезная и сложная тема, которая требует от слушателей не только напряжения внимания, но и достаточного опыта в энтерпрайз разработке приложений с запутанной бизнес-логикой. И горьким личным опытом как относительно простые и понятные приложения с течением времени превращаются в комок грязи, если в архитектуре кода не была предусмотрена изоляция слоев.
Хороший доклад! Еще из практики я бы посоветовал Get your hands dirty with Clean Architecture. Можете подсказать где почитать лучше про event driven, как это здесь сделано. Заинтересовало
Подскажите как называется тема в IDEA, используемая в докладе)
Окей, вдруг нам понадобилось масштабировать какую-то часть доменного слоя? Выделить в отдельный сервис. Что будем делать? Проще же было изначально разбить на доменные модули приложения, и для каждого из них сделать отдельные слои с портами, адаптерами. Разве нет?
Спасибо за интересный доклад! А исходники будут?
Привет! Вот ссылка - github.com/conacry/santa-post-ca
Подарок, знает ребенка и проверяет его поведени ? Интересная логика из реального мира.
Мне кажется, что первоначально было написано через ДДД'шныц агрегат, но позже решили упростить и убрать его. Хотя полностью согласен, в таком контексте выглядит не очень
Почему подарок знает про ребёнка? Ещё и решает, какого размера ему быть в зависимости от поведения ребёнка?! Ничего не смущает? Дальше не смотрел.
А что не так? Ну не ребёнку же решать, какого размера получать подарок
Предложи свой вариант, как должно было быть
))) сопит как паровоз, когда зачем-то пишет код, хотя у самого уже готовый проект имеется, можно спокойно показывать и рассказывать. Но парень, видно, не ищет легких путей))
Когда пишется код, можно следить за мыслью спикера. Когда он уже показывает кучу готового кода, это сложнее для зрителя. Надо изучить код, войти к контекст. Поэтому, лайвкодинг хороший вариант.
И почему то в докладе про чистую архитектуру в коде ей удален 1%, а оставшиеся 99% это бизнес логика (проверки, валидации и т.п.)
Это просто кашмар! Ребята найдите нормального архитектора. Меня просто порожает уровень докладчика.
Хуже этого доклада не видел за очень долгое время...просто отвратно донес идею Дяди Боба....лучше читать статьи с докладами в оригинале чем такое
Не поделишься ссылками, или своей версией реализации?