Максим Морев - DDD в действии

Ближайшая конференция - 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

[@zugzug90]

Довольно сумбурно и было очень сложно следить за нитью повествования.. 😢

[@prng792]

Интересный доклад, хотелось бы посмотреть git репу, о которой в начале доклада. К сожалению, по ссылке страница закрыта авторизацией и регистрации нет.

[@user-fq3nn3ql3g]

Вообще, подлый поступок! Поделится ссылкой на закрытый репозиторий. Надеюсь в аду для тимлидов Максиму персональное место выделят)))

[@ii99xt1]

Вы же понимаете что доклад был полгода назад, и за это время что-то могло измениться?

[@daniilkahov4521]

​@@ii99xt1он же понимал, что доклад будет записан, и не стоило чего-то менять

[@vovik0134]

Сейчас уже QR-код работает и репозиторий открыт публично

[@averv]

Хороший доклад. Смотрю на примеры - похоже на построение идеоматичного rust-кода (сам знаком поверхностно), там на уровне языка возвраты Result их очень удобная обработка, построение программы в виде пайпа, удобнейшее написание тестов рядом с кодом и т.д. Рад что в Kotlin тоже многое есть.

[@SkyAntins]

Доклад ни о чем, не тратьте время, если у вас есть хотя бы минимальный опыт в разработке. В докладе нет конкретных примеров - как было/как стало, каких-либо метрик и kpi, чтобы доказать что такой подход чем то лучше классического. Максимум были приведены подходы, которые никак не относятся к DDD и применяются и в стандартных 3-слоевых архитектурах. По сути из аргументов были только подобные: мы сделали лучше, читаемее, наш код стало легче поддерживать и бла бла бла. Без конкретных показателей это все пустая болтовня, каждый разраб считает свой код читаемым, но это не всегда так

[@57skies]

same thoughts after about 15 minutes of watching this.

[@kirillsh8383]

я в разработке более 12 лет уже. DDD и TDD и BDD это сферические кони в вакууме. В чистом виде это оверинженеринг и затянутые процессы, более того крайне редко заказчик знает и документирует треборвания от А до Я вначале проэкта и готова по 3-4 раза в день делать созвоны и обсуждать каждую фичу и нюанс.

[@Chanel20235]

Указанный в начале репозиторий не доступен для просмотра, сильно неприятно А так тема интересная. Минус докладчика, что он предполагает, что слушатель тут же быстро прочитывает все, что написано на слайде и половина того, что дб проговорено не проговаривается и остается впечатление немного сумбурности вещания ...

[@user-fg3ed2gz7y]

я долго слушал, мне сказали что рассказывать можно долго, даже таймер поставили что бы не выходить за тайминги, но вот уже 8 минут и ничего про DDD еще не было сказано

[@bulsond]

Не совсем понятно как можно обойтись без моков. Если в use case присутствует взаимодействие с репозиторием, то как можно такой случай протестировать без мока?

[@ivanmatew568]

Посмотрите выступления Владимира Хорикова

[@ivanmatew568]

И почитайте его книгу

[@bulsond]

@@ivanmatew568 Спасибо, за направление на источник правды, так сказать. А вы можете в двух словах сформулировать ответ на мой вопрос без отсылки на авторитеты?

[@SkyAntins]

Вангую что там будет монструозное решение, которое сделает тесты переусложненными или вообще нечитаемыми. Зато от моков избавились)

[@bfdhtfyjhjj]

Создать интерфейс репозитория(и в типах юзать его а не реализацию) и в тестах юзать InMemoryRepository(Repository) вместо того который в бд лезет

[@dmitrysivolovskiy]

где тут действие непонятное. теория теория теория. а потом функциональное программирование и ничего про ДДД

[@Psyjewnaut]

Коротко: нужно не нанимать толковых программистов, понимающих, как работают системы, а нанимать вайтишников кодеров, которые вчера прочитали лекцию про кафку и уже эксперты обмена информацией в тяжелых системах (а потом крутят её на чат бота с 100 rps в день) Как-то с парикмахером подобное обсуждал: Несколько лет учёбы в столичном унике и 10 лет практики - парикмахер как парикмахер, 700 руб Неделю назад приехал с Таджикистана, ниразу не держал ножницы в руках, но прошёл курсы барбершопа и уже крутой специалист за 1500 руб

[@newplanetfa11]

норм

[@user-zl3zj2ut5o]

Доклад возможно и хороший, но за первые 15 минут, что я осилил, про DDD ни слова. Кто будет смотреть, начало можно пропустить.

[@egorka464]

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

[@user-xv1iq3km2w]

Ну да, как интересно мы сделаем рич модель если у нас есть куча сущностей которые надо таскать из бд, если только рассмотреть с другой точки зрения и представить что агрегат это тот же сам себе сервис которому нужно скормить репу или функцию чтобы подтянуть данные, гемофродит на выходе. Я сам вот только недавно начал погружаться в DDD, и все никак не могу для себя найти эту грань как было бы удобнее и таскать данные и одновременно с этим сложить в SRP логику конкретной модели которая работает с другими а у неё свои сервисы, всю голову сломал, но никак не могу представить себе рич модель учитывая реальность а не красивые картинки в пару функций без логической каши процесса заказчика