Deworker Pro

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

Сегодня вечером начинаем стрим.

Если до или после завтрашнего стрима появится желание вспомнить содержание прошлого стрима, то для удобства просмотра добавили тайм-коды: https://deworker.pro/blog/stream-modules

До повышения цены на стрим осталось меньше двух часов. Не опоздайте приобрести участие со скидкой!

На декабрьском стриме мы познакомились с идеями разделения кода на модули и микросервисы. Мы разобрали всё это на своём примере большого магазина, но от вас поступили предложения сделать это и на ваших примерах для ваших предметных областей. Также часто спрашивают о том, как раздробить на модули или микросервисы не новый, а уже имеющийся монолитный проект. Пришла пора ответить на эти вопросы и рассмотреть паттерны и антипаттерны разделения кода на других примерах. И показать практики по разделению уже существующих проектов. Это мы сделаем на новом большом практическом стриме. До встречи в эфире с участниками!

Помимо отдельных вопросов сегодня добавлено много интересных вопросов с подробными ответами из комментариев: https://deworker.pro/qna/comments

📌 Новые ответы на ваши вопросы Наш раздел пополнился четырьмя вопросами ⬇️ ❓Как перейти на Symfony и разделить проект? У меня есть проект, который по факту несколько веб сайтов: бекенд, фронтенд и API на разных доменах. Через API происходят все запросы, начиная от логина, заканчивая выборкой статей и товаров. Сейчас это всё на Zend монолите с ужасным кодом. Решил перейти на Symfony. Но теперь вопрос: как эти три сервиса разнести? ❓Выбор PHP фреймворка Хочу узнать ваше субъективное мнение по поводу выбора PHP фреймворка как основного для разработки сайтов. Нужно начинать пользоваться фреймворком, но пока стою перед выбором из Laravel, Symfony и Yii. В будущем возможно придется поработать на каждом, но начать хочу с того, какой содержит в себе лучшие практики проектирования. ❓Как парсить большие XLS-документы? Что лучше использовать для парсинга больших XLS документов, где внутри для каждой строки нужно делать много проверок в соответствующих полях, формировать массив и записывать в базу. И в последующих импортах нужно будет и редактировать те что уже записаны и вносить изменения. Это очень трудоемкая операция. Работаю на PHP использую PHPOffice. Может стоит написать самому или использовать какой то NodeJS. ❓Где брать компоненты для микрофреймворков Микрофреймворки предоставляют минимальный набор компонентов, но где брать остальное: например, валидацию форм, работу с сессиями, Redis и т.п.? Есть ли некий список общепризнанных, актуальных и поддерживаемых компонентов "де-факто", и если да, можно ли его где-то найти? Переходите по ссылкам и присоединяйтесь к диалогу в комментариях.

От примера с грузоперевозками переходим к реальному моделированию. Запускаем сессию Event Storming и сегодня строим большую картину этапа Big Picture. Прорабатываем создание и уточнение лота, автоматическую и ручную модерацию лота для запуска торгов.

Наша сессия Event Storming для аукциона будет весьма эпичной. Впереди у нас группы скринкастов по этапу Big Picture и по остальным шагам. Полностью проработаем управление лотами, торги, оплаты и все этапы сделки. А пока догоняйте нас в этой серии, если ещё не всё посмотрели.

Большой эпизод про DDD и Event Driven архитектуру для построения слабосвязанных систем открыт для общего доступа. Приятного просмотра всем, кто его ещё не видел или хочет пересмотреть всё заново!

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

Разработка разработкой, но помимо неё приходят интересные новшества. Теперь устанавливать и работать с Docker Compose стало проще. В связи с этим сегодня переведём на новый Compose V2 наш проект вручную и наши Jenkins и Registry серверы автоматизированно через Ansible.

Разработка разработкой, но помимо неё приходят интересные новшества. Теперь устанавливать и работать с Docker Compose стало проще. В связи с этим сегодня переведём на новый Compose V2 наш проект вручную и наши Jenkins и Registry серверы автоматизированно через Ansible.

Новые зрители (и те, кто повторно пересматривал прошлые эпизоды) сталкивались с трудностью, что код из репозитория аукциона не запускался на предыдущих коммитах из-за несовместимости со свежими Composer или Xdebug. Сейчас это исправлено. Репозитоий перепроверен и во всех ключевых коммитах в Dockerfile вписаны совместимые версии. Теперь проект успешно запускается командой make init из любого предыдущего коммита. Если вы раньше клонировали к себе репозиторий, то склонируйте его снова или загрузите новую историю через git fetch.

Помимо комментариев на сайте много обсуждений проходит в разных чатах. Но полезные ответы в них безнадёжно теряются. Чтобы это решить мы в разделе с вопросами и ответами открываем новую ветвь, куда будем цитировать свои ответы из чатов и из других переписок. Сегодня опубликованы первые 7 вопросов и ответов. Приятного чтения!

Начинаем моделирование предметной области проекта аукциона. Сегодня рассмотрим домен и поддомены для нашего бизнеса с точки зрения DDD. Перейдём на Event Driven архитектуру для проведения сложных бизнес-процессов в системе слабосвязанных модулей. Познакомимся с практикой Event Storming для построения цепочек команд и событий.

Начинаем моделирование предметной области проекта аукциона. Сегодня рассмотрим домен и поддомены для нашего бизнеса с точки зрения DDD. Перейдём на Event Driven архитектуру для проведения сложных бизнес-процессов в системе слабосвязанных модулей. Познакомимся с практикой Event Storming для построения цепочек команд и событий.

После перехода на PSR-7 мы уже понимаем, как делать переносимыми функции, которые работают с переданным им Request-ом. Но пока не знаем, что делать с функциями, которые у себя создают Response. Поэтому помимо других инверсий сегодня рассмотрим инверсию контроля за созданием зависимостей. Это нам позволит отвязаться от конкретных классов и понять причины появления PSR-17. Помимо этого рассмотрим заблуждение многих PHP-програмистов при написании анонимных функций. Почему класс для них назван Closure и являются ли все анонимные функции замыканиями.

Мы редко пишем весь проект полностью с нуля. Вместо этого мы активно используем готовые компоненты от других программистов, подключая через Composer. И если у нас несколько проектов, то может возникнуть желание вынести свой код в отдельную библиотеку, чтобы использовать её у себя или даже поделиться публично. Но если код сильно связан с остальным кодом проекта или фреймворка, то вынести его в отдельную библиотеку весьма сложно. Сегодня как раз рассмотрим повторное использование кода и на примере нашей функции покажем способы избавления от лишних связей через инверсию зависимостей. И в итоге для написания переносимого кода перейдём на PSR-7 и совместимые с ним готовые компоненты.

Спасибо участникам за отличную вчерашнюю компанию! Вначале по традиции поборолись с техникой, но в итоге стрим удался. В карточке сейчас вывели ссылку на оригинальную запись. В будущем постараемся немного смонтировать видео и убрать различные заминки, чтобы всё смотрелось более интересно. Ещё в посте выложили изображения, нарисованные нами на стриме. Может кому-то пригодятся.