Максим Морев - DDD в действии
ฝัง
- เผยแพร่เมื่อ 14 ก.ย. 2023
- Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
Доклад-руководство с примерами на Kotlin по внедрению предметно-ориентированного проектирования (Domain Driven Design) в команду и обращения ее в безумную машину по доставке чистого кода. С собой вы унесете паттерн приложения с тестами на бизнес-логике и кучу полезных рекомендаций, которые работают.
Спикер расскажет, как коммуникация, документация, юзабильность кода, функциональное программирование, Type Driven Development, Test Driven Development поможет выйти на новый уровень.
Сложности:
- не говорить про DDD;
- внедрение кукбука в существующей команде;
- рефакторинг существующего «старого» кода по кукбуку.
Презентация к докладу: squidex.jugru.team/api/assets...
#java #architecture - วิทยาศาสตร์และเทคโนโลยี
Довольно сумбурно и было очень сложно следить за нитью повествования.. 😢
Хороший доклад. Смотрю на примеры - похоже на построение идеоматичного rust-кода (сам знаком поверхностно), там на уровне языка возвраты Result их очень удобная обработка, построение программы в виде пайпа, удобнейшее написание тестов рядом с кодом и т.д. Рад что в Kotlin тоже многое есть.
Интересный доклад, хотелось бы посмотреть git репу, о которой в начале доклада. К сожалению, по ссылке страница закрыта авторизацией и регистрации нет.
Вообще, подлый поступок! Поделится ссылкой на закрытый репозиторий. Надеюсь в аду для тимлидов Максиму персональное место выделят)))
Вы же понимаете что доклад был полгода назад, и за это время что-то могло измениться?
@@ii99xt1он же понимал, что доклад будет записан, и не стоило чего-то менять
Сейчас уже QR-код работает и репозиторий открыт публично
я долго слушал, мне сказали что рассказывать можно долго, даже таймер поставили что бы не выходить за тайминги, но вот уже 8 минут и ничего про DDD еще не было сказано
Доклад ни о чем, не тратьте время, если у вас есть хотя бы минимальный опыт в разработке. В докладе нет конкретных примеров - как было/как стало, каких-либо метрик и kpi, чтобы доказать что такой подход чем то лучше классического. Максимум были приведены подходы, которые никак не относятся к DDD и применяются и в стандартных 3-слоевых архитектурах.
По сути из аргументов были только подобные: мы сделали лучше, читаемее, наш код стало легче поддерживать и бла бла бла. Без конкретных показателей это все пустая болтовня, каждый разраб считает свой код читаемым, но это не всегда так
same thoughts after about 15 minutes of watching this.
я в разработке более 12 лет уже.
DDD и TDD и BDD это сферические кони в вакууме.
В чистом виде это оверинженеринг и затянутые процессы, более того крайне редко заказчик знает и документирует треборвания от А до Я вначале проэкта и готова по 3-4 раза в день делать созвоны и обсуждать каждую фичу и нюанс.
Указанный в начале репозиторий не доступен для просмотра, сильно неприятно
А так тема интересная.
Минус докладчика, что он предполагает, что слушатель тут же быстро прочитывает все, что написано на слайде и половина того, что дб проговорено не проговаривается и остается впечатление немного сумбурности вещания ...
Не совсем понятно как можно обойтись без моков. Если в use case присутствует взаимодействие с репозиторием, то как можно такой случай протестировать без мока?
Посмотрите выступления Владимира Хорикова
И почитайте его книгу
@@ivanmatew568 Спасибо, за направление на источник правды, так сказать. А вы можете в двух словах сформулировать ответ на мой вопрос без отсылки на авторитеты?
Вангую что там будет монструозное решение, которое сделает тесты переусложненными или вообще нечитаемыми. Зато от моков избавились)
Создать интерфейс репозитория(и в типах юзать его а не реализацию) и в тестах юзать InMemoryRepository(Repository) вместо того который в бд лезет
Коротко: нужно не нанимать толковых программистов, понимающих, как работают системы, а нанимать вайтишников кодеров, которые вчера прочитали лекцию про кафку и уже эксперты обмена информацией в тяжелых системах (а потом крутят её на чат бота с 100 rps в день)
Как-то с парикмахером подобное обсуждал:
Несколько лет учёбы в столичном унике и 10 лет практики - парикмахер как парикмахер, 700 руб
Неделю назад приехал с Таджикистана, ниразу не держал ножницы в руках, но прошёл курсы барбершопа и уже крутой специалист за 1500 руб
Доклад возможно и хороший, но за первые 15 минут, что я осилил, про DDD ни слова. Кто будет смотреть, начало можно пропустить.
где тут действие непонятное. теория теория теория. а потом функциональное программирование и ничего про ДДД
норм
Показано всеПолучается, что суть DDD, в том чтобы пихать простую логику, не требующую, внешних обращений в сам агрегат, а вся остальная, более сложная, логика все равно вынуждена будет уехать в сервис.
Ну да, как интересно мы сделаем рич модель если у нас есть куча сущностей которые надо таскать из бд, если только рассмотреть с другой точки зрения и представить что агрегат это тот же сам себе сервис которому нужно скормить репу или функцию чтобы подтянуть данные, гемофродит на выходе. Я сам вот только недавно начал погружаться в DDD, и все никак не могу для себя найти эту грань как было бы удобнее и таскать данные и одновременно с этим сложить в SRP логику конкретной модели которая работает с другими а у неё свои сервисы, всю голову сломал, но никак не могу представить себе рич модель учитывая реальность а не красивые картинки в пару функций без логической каши процесса заказчика