Уроки, менторство boosty.to/sashokgorshok

Пожалуйста, продолжайте делать цикл, очень полезно. Особенно как ваш контент для уровня от мидла и выше

Спасибо, очень классный контент!

Привет! Давно ждал продолжение! Очень интересно!

Очень хороший контент! Доступно

спасибо огромное!!!) продолжайте это благое дело! )

Cаша привет! Спасибо за старания и за подробное объяснение, продолжай делать то что делаешь, у тебя все очень классно получается, жду с нетерпением продолжения курса. До дыр пересмотрел.

Спасибо за контент!

Лучшие уроки по ддд и симфони. Спасибо за труд Алехандро!

@AlejandroYakovlev

Жыл бұрын

Рад стараться! :)

Зачетный видос!

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

Лайк подписка, продолжайте пожалуйста очень ценно

Большое спасибо!

Привет, ждем продолжение

Спасибо!)

Спасибо )

Ніфіга не зрозуміло, але дуууже цікаво!! 😂 навіть після девʼяти попередніх уроків, для мене поточне відео було подібне до "як намалювати сову".... тільки розібрали модуль User, а тут фігак і все готове і розбиратись самому далі треба 😳 Дякую Олександре за найцікавіші і найкорисніші уроки, та схоже мені вони трохи "на виріст", додивлюся останній урок по CI/CD й піду розбиратись із базою Сімфоні

Спасибо!

Добрый день! Решил как раз посмотреть за симфони, а то лара уже как то скучна стала) И как раз первое, что пришло на мысль это архитектура в симфони и с чего начать) Материал весьма полезный, подача хорошая! Надеюсь будете продолжать вести канал и на это у вас будет свободное время! Очень редко пишу комменты, но тут прям 10 из 10

❤❤❤🎉🎉🎉

Как я рад, что ты вернулся! Спасибо за твой труд, очень полезные для меня видео. Я начинаю осваивать симфони, по твоим видео начинаю потихоньку кодить))) Было бы круто, если бы ты смог выпустить пару роликов для совсем чайников, как въехать в симфони, т к много чего еще не доганяю, хоть юзаю гугл и доки.. и было бы оч круто, если бы ты выпустил видео про архитектуру проекта и примеры бест практис, но для совсем зеленых))) что бы все это лучше уложилось в голове. Спасибо!!!

@fitter2boss72

Жыл бұрын

Материал "для чайников" пилят все кому не лень, а для мидлов и выше мало кто. Не отвлекайте автора ! :)

@AlejandroYakovlev

Жыл бұрын

@@fitter2boss72 😄, я все же думаю позже позаписывать обучающие видео для "чайников", чтобы прокачать свои навыки в плане менторства и донесения мыслей. Всё же мидлы многое на лету умею схватывать и додумывать, так как есть база, а вот заложить базу для начинающего - этому еще нужно поучиться )

@fitter2boss72

Жыл бұрын

@@AlejandroYakovlev А вы где-то менторствуете еще ?

@AlejandroYakovlev

Жыл бұрын

Если только неосознанно :)

@user-gq2zk4lv9z

Жыл бұрын

@@AlejandroYakovlev спасибо большое, буду ждать!)))

Еще есть просьба, когда показываете код в Шторме не обрезайте верхушку, в которой видно путь до функции.

I just found your channel and it covers many topics that i'm searching. Unfortunate for me I don't know Russian. I just hope there are a subtitle for the video.

Спасибо большое, очень ценно. Будет ли продолжение?

Отличное объяснение основ ddd. Жаль видео не было когда я изучал. Зависимость сущностей от каких то сервисов и тп можно наверно завернуть в фабрики. Это я про зависимость от спецификаций

Хороший материал, спасибо! Лично мне не особо нравится прокидывание спецификации через postLoad ну или других сервисов, я сам сталкивался и так делал, костыльное решение, ну еще есть моменты когда ОРМ не позволяет делать красивые настоящие ООП объекты. Я последнее время начал задумываться, вообще при ДДД уходить от энтити менеджера, а сделать сохранение/получение делать агрегатов из БД на DBAL.

скажите пажалуйста почему не работает команда make test выдает ошбку нету файла или директории 127. Хотя все файлы на месте. Сборока запус контейра продит все ок, если тесты запускаю в конейнере php bin/phpunit все ок и все команды test: jwt: cache: выдают такую ошибку

Hi Is it possible to have a blog post in english ?

@AlejandroYakovlev

10 ай бұрын

No :( But you can find the best information in the book "Vaughn Vernon. Domain-Driven Design Distilled". When writing the script for the video, I relied on the content of this book.

Я как-то потерялся, какова наша предметная область для разрабатываемого Апп? Типа HR компании? (Я конечно извиняюсь за такой тупой вопрос, но большая пауза дает о себе знать. Это идет тотже проект?). Спасибо.

@AlejandroYakovlev

Жыл бұрын

Я проводил опрос в ТГ канале, где силой большинства было принято решение в рамках урока рассматривать функционал оценки навыков сотрудников. Это что-то из области HR и обучения. Посмотрим, как пойдет дальше. Чтобы не засорять основной репозиторий бизнес логикой, скорее всего буду форкать основную ветвь для различных примеров.

@fitter2boss72

Жыл бұрын

@@AlejandroYakovlev Я наверное тоже там за что-то голосовал :) Меня видимо сбило то, что вещи о которых говорится, так же присутствуют в начале разработки (навыки , команда , опыт, инструментарий). Спасибо.

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

@AlejandroYakovlev

Жыл бұрын

Спасибо. Конечно, все зависит от ситуации. Слишком тяжелые богатые модели не есть хорошо. Бизнес логику можно вынести в спецификации, чтобы не нарушать принцип единой ответственности. Различные условия можно обыграть через стратегии. Можно и в сервисы на доменном слое. Как только появляется сложность, нужно заниматься рефакторингом в правильном русле. YAGNI. Что бы вы хотели услышать про DTO?

@sergeidavidenko8885

Жыл бұрын

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

@AlejandroYakovlev

Жыл бұрын

@@sergeidavidenko8885 сущности не должны выходить за границы domain и application слоев, это верно. DTO можно использовать для передачи состояния между ограниченными контекстами, для передачи состояния между слоями. Чаще DTO хранится на приклодном слое (например, в CQRS подходе в запросах происходит маппинг сущности). Не думаю, что DTO это часть DDD. Как минимум про DTO ни Вернон, ни Эванс в своих книгах не рассказывают. Да и рассказывать про него особо то нечего :) Это простые структуры, часто иммутабельные, содержат геттеры и сеттеры, методы маппинга и серриализации. Пусть их будет хоть сотни, лишь бы несли свою полезную нагрузку.

А как сделать админку на DDD? В модуле добавить подмодуль админку? Ведь там используется та же сущность что и на фронт части

@AlejandroYakovlev

Жыл бұрын

Можно отдельным модулем. Плюсы: низкая связанность, высокое зацепление. Минусы: придется писать больше кода, возможно, с грустью дублировать код в порыве следовать принципам Закона Деметры . Модульный подход поможет впоследствии вынести админку из монолита в отдельную веб службу. Или оставить админку, а все остальное распилить на микрослужбы. Если админкой назвать совокупность модулей, каждый из которых можно представить в виде раздела админки, то контроллеры и представление можно разместить на инфраструктурном слое каждого из модулей. Плюсы: меньше кода (хотите юзать сущности напрямую, без всяких адаптеров и дтошек - пожалуйста) Минусы: модули будут слишком завязаны на представлении, код станет более грязным, хоть и не превратится в большой ком. Еще нужно смотреть какую роль админка занимает в бизнесе, ее стратегическую важность, назначение. Что есть кроме админки и как в будущем это планируется масштабировать. По хорошему админку нужно делать отдельной службой, работающей отдельно от основного приложения и работающей через отдельную схему API (REST, RPC). Если это, например, CRM, ERP, CMS для бизнеса.

@user-pd9mn5yf9f

Жыл бұрын

​@@AlejandroYakovlevА как админка может работать отдельным службой, когда используются те же таблицы с теми же данными, которые и в основном приложении. А если же просто делать отдельным модулем (не вынося в отдельную службу), придется скопировать доменные модели в другой модуль, то есть с теми же полями и с теми маппингами и именем таблцы (чтобы иметь возможность работать с той же таблицей и с теми данными, с которой работает и доменная модель в основном приложении)

@timur43378

10 ай бұрын

Вопрос некорректен. На DDD делается какая-либо предметная область. Админка - это просто отдельные контроллеры, доступные определенным юзерам. Админка будет использовать тот же "доменный код", что и паблик часть.

Здравствуйте, Александр. Можно, пожалуйста, ссылки на презентацию и схему из ролика 🙂

@AlejandroYakovlev

Жыл бұрын

Здравствуйте. Ссылку на презентацию Вы найдете в моем ТГ канале t.me/alexgorshok

@user-cs7mb8tn9s

Жыл бұрын

@@AlejandroYakovlev спасибо. Нашел там ссылку только на презентацию. Нет ссылки на схему. Или вы не хотите её выкладывать?

@AlejandroYakovlev

Жыл бұрын

@@user-cs7mb8tn9s открыть доступ к схеме, к сожалению, не могу. Та как там на одной доске есть приватные данные, не относящиеся к уроку.

Жаль больше нет уроков.

Классный урок, почему нет новых видео?

@AlejandroYakovlev

5 ай бұрын

Скоро будет 💯

Спасибо за видос! Но юзать спецификацию, через которую потом инжектится Repository такое себе решение. Это нарушает изоляцию доменной модели, я бы в таком случае жертвовал инкапсуляцией и выносил бы такую логику в доменный сервис.

@AlejandroYakovlev

Жыл бұрын

Вы правы. Это слабое место.

Едрить сложна. Слоожнаа😮

@AlejandroYakovlev

7 ай бұрын

По началу всегда так. Это нормально. Когда спустя время вернешься к этой информации, уже легче восприниматься будет.

Модуль !== Ограниченный контекст !== Поддомен. Парень, учи матчасть.