По больше таких стримов, Kotlin, Python, Rust - все и так изучают, а вот правильное проектирование и системный дизайн это то, чего так не хватает. Спасибо )
Первый раз смотрю подобное видео - случайно попало в рекомендованные. Очень интересно было посмотреть и понять ход мыслей разработчика при работе над проектом. Я как маркетолог часто слышал обрывки диалогов программистов и теперь более понятно о чем идут столь оживленные дискуссии ) Ну и, по правде говоря, при работе над улучшением продукта, мне реально интересно знать как этот продукт устроен технически. Теперь ясно как в целом работает приложение. Было бы интересно в таком же формате разбор от ПМа, продакта и бизнес аналитика. P.S. Кому нудно - включайте на х1,75. Отлично смотрится.
Более содержательного видео не могу вспомнить, пусть поверхностно, но за полтора часа дать такое комплексное описание целого, почти реального проекта, это просто вау, что самое главное понятное. Премного благодарен автору, подписка однозначно.
Почитал комментарии и аж обидно стало. Видео просто пушка. Автор сразу же обозначил цель видео, наложенные ограничения и в чём вообще задумка и мне кажется, автор цели достиг, с задачами справился и ограничения учёл. Видео, на мой взгляд, получилось очень информативным, полезным и интересным. Процесс проектирования сложных сервисов действительно показан хорошо. Даже если бы обсуждался реальный сервис - уже было бы от чего оттолкнуться и что начать обсуждать командой из нескольких человек, а не в одно лицо. Такой результат за полтора часа - это очень круто(понятно, что автор потратил больше, чем полтора часа, рисование схем, продумывание сценариев - это довольно много времени, но всё же). Да, много моментов, которые просят пояснения, много где можно подискутировать и поспорить, но видос не про это вовсе. Сергей, большое вам спасибо! С дикцией у вас тоже всё отлично, да и в конце концов, вы не теледиктор, вас не за красоту слога приходят смотреть.
Огромное тебе спасибо, Гэри Олдман, за прекрасное изложение материала ещё и на русском. Посмотрел за раз, не отрываясь. Успеха тебе в ютуб-пространстве.
На редкость полезное видео. Дизайню интерфейсы, чисто из любопытства решил поинтересоваться за архитектуру - теперь всё прям по полочкам расставилось. Спасибо.
Спасибо, посмеялся. Классическая ошибка "микросервисы ради микросервисов", аналогично redis и rabbitMQ. Аналогично столь подробное планирование архитектуры простого проекта. При этом нет обоснования выбора того или иного пути.
Согласен. Вместо одного большого монолита мы сделаем кучу сервисов, которые юзают одну и туже бд. По сути получился распределённый монолит, с кучей побочных проблем: deploy, масштабирование, сомвестимость api
Вы всё верно пишете, но задачи спроектировать коммерческий проект я для себя не ставил при подготовке к этому видео. Цель видео - озвучить ход мыслей, и схематично показать процессы проектирования. Основная моя ЦА - джуниоры и те кто готовится к своей первой работе, я стараюсь чтобы понятность моего контента соответствовала целевой аудитории. Вопросы монолита и микросервисов, очередей и прочее - вопросы более высокого уровня, для понимания и обсуждения которых нужен определённый уровень и опыт. Но так как на канал приходят люди с таким опытом, как вы, например, постараюсь в будущем делать более явный дисклеймер на эту тему. Спасибо за фидбек.
@@radik353 очень странный подход - показывать именно формально бюрократическую часть работы, гиперболизируя её и не объясняя логики. Ну да бог вам судья
Спасибо, очень любопытно посмотреть как этим занимаются на практике. Я и сам учусь на программиста самостоятельно и понимаю, что самое главное в этом деле - архитектура. Это - начало начал и именно этим мне и нравится заниматься, нежели кодингом. Изучил немного тему EDA, событийно-ориентированной архитектуры и DDD, предметно-ориентированный дизайн приложений. Считаю, что это лучшая связка для архитектуры практически любых приложений, так как события убирают связность между модулями, а предметные области позволяют правильно разбить приложение на отдельные службы. У вас разбивка похожа на DDD, но отличие в том, что у вас все данные хранятся в одном месте, что противоречит DDD. По DDD каждая служба (сервис) должна хранить свои данные в своей независимой базе (теоретически СУБД можно использовать одну, но базы должны быть разные). По DDD каждая предметная область содержит как данные, так и логику для их обработки (по сути как и объект в ООП), что создаёт изоляцию и независимость от других предметных областей. А это даёт больше свободы и простоты в поддержке. Можно любую предметную область удалить, добавить, и это будет абсолютно не заметно для других, если используются события для общения, а не прямые RPC и прочие такие запросы с ожиданием ответа. При чисто событийной архитектуре всё общение идёт через шину событий, и она является единственным модулем, с которым напрямую связаны все предметные области. А это - максимальная изоляция друг от друга - то, к чему стремятся многие программисты, понимая весь ужас и тяжесть монолитных и спагеттеобразных приложений, где все связи между модулями и данными прямые. Не лучше ли всё-таки использовать DDD?
Согласен с вашими рассуждениями о ценности DDD. В этом видео моей целью было по продемонстрировать ход мыслей при проектировании и наглядно по верхам показать схемы, БД, API. Но проект я выбрал довольно сложный, плюс, полтора часа - и так уже много, поэтому местами вышло поверхностно. В последующих видео по проектированию стараюсь не повторять эти ошибки.
Это действительно важное принципиальное замечание, т.к. если уж упомянули о микросервисной архитектуре, то надо придерживаться и требований к микросервисам (у каждого свои данные). Иначе для тех, кто только начинает постигать системный анализ это может надолго создать неправильный подход.
Это что-то конечно..случайно наткнулся на это видео и буквально залип. Огромное спасибо автору за очень ценный урок и прекрасное, доходчивое объяснение!
Проходили про базы данных в вузе, про бек и фронт - на тестовых заданиях в ШМЯ. А вот про API не знала, это было новым. Спасибо! Это круче, чем онлайн курс.
Спасибо, крутое видео, не каждый выкладывает структуру реального проекта и процесс проектирования. Вроде простое приложение, но офигеть насколько сложной схема получается, и это без всяких нюансов и общепринятых каких-то дополнений.
Спасибо за отзыв. Всё-таки это не архитектура реального проекта, а скорее упрощенная демонстрация хода мыслей, с которыми подходят к проектированию. Очень многое не рассмотрено, но и так полтора часа получилось.
отдельно понравилось рассуждение "ну сейчас все делают микросервисы поэтому мы тоже сделаем их" чевооооооо с ровного места огромные оверхеды разработки добавлены
В таблицу Orders я бы добавил не одно поле timestamp, а что-то типа created и delivered - дата создания заказа и его доставки. Также можно было бы добавить таблицу а-ля "Order_Rating" со связью по полю id таблицы Orders, где была бы оценка заказа и комментарии по нему.
Пока что отсмотрел не всё, но очень интересное видео. Показывает как можно и на что разбить проект, чтобы дальнейшая разработка шла по сформированной программе. И самое главное, что это прямая трансляция, где всё происходит без вырезания некоторых сцен(хотя понятно, что вопрос рассматривался ранее и рассматривались разные варианты).
Спасибо. Очень полезная информация. На кого же похож автор. Мне кажется на Жан Батист Эммануэль Зорг - вымышленный персонаж, главный злодей научно-фантастического фильма Люка Бессона "Пятый элемент". Сыгран знаменитым британским актером Гари Олдманом. )
25:11 Интересный подход, вроде все просто но раньше не приходило такое в голову, спасибо. Получается помесь BPMN и проектирования, на чистом BPMN конечно сам процесс был бы более качественно описан, но зато в таком виде удобно изучать архитектуру. В работе постоянно есть выбор между "обобщить" и потерять часть информации или "детализировать" но в итоге перегрузить схему так что она становится не читаемой. Вам удалось соблюсти хороший баланс. Это тоже важный навык который требуется нарабатывать.
@@zhukovsd_it_mentor тебе спасибо за видео, для меня это новый мир особенно те видео где ты разбираешь проекты, то как искуссно ты говоришь о недостатках при этом не обижая людей но в то же время конструктивно это что то недостижимое. Я сам по работе лид и делаю ревью кода Джунов и мидлов и приходится так же общаться с людьми, естественно я стараюсь быть минимально токсичным, но по сравнению с тем как ты это делаешь Я просто ребенок)). Очень много полезных приемов общения у тебя увидел. Писать код на самом деле самое простое что есть в работе Лида. Самое сложное это давать обратную связь и уметь явно излагать свои мысли. Если это читают начинающие ребята то мой совет учитесь у этого человека излагать мысли это гораздо важнее умения писать код)))
я - весьма токсичный и нередко гажу в комментах (борюсь с этим, но не всегда получается). А это видео - тот случай, когда хочется поблагодарить автора за проделанную работу!
Классный ход мысли. Видно, что много раз делали подобный дизайн. Интересно, можно ли получить подобный ход мысли на синтетических задачах проектирования?
@Jilexa Самое главное - в рабочих проектах учиться у старших коллег и постепенно участвовать в проектировании. По книгам: - Проектирование бизнес логики - Domain Driven Design by Eric Evans - Software Architecture Patterns - Если в проекте есть БД, SQL/NoSQL, хорошо почитать что-то про проектирование хранилища, например книгу "SQL Antipatterns"
Практическая реализация этого проекта не планируется, идея видео - описать ход мыслей при проектировании. Но мне интересно было бы продолжить эту серию видео, спроектировав что-нибудь ещё, поэтому буду рад услышать предложения.
Остановил ролик после проектирования бд. Очень поверхностное проектирование вообще при довольно сложной темы как агрегатор доставки еды. А номер позиции в меню? А категория блюда? А правила для заказа (минимум ценик заказа, расстояние между клиентом - рестораном )? А возможность убрать ингредиент? А если сеть ресторанов? А как сама агрегация ресторанов будет происходить? А возможность отзыва? и тд тп... уж лучше сделали подробно онлайн заказ у одного ресторана. ТЗ уровень описания того самого клиента на фриланс платформе, который не понимает что хочет и ничего толком не знает (сто пудов кинет и у него будут круглые глаза когда узнает сроки\цену). Ну и хранение постоянно меняющееся coorinates курьера в холодном хранилище, даже теоретически, конечно убило.
Случайно попал на видео, у заказа нужны свойства(уже стандарт) свойства заказа могут быть разного типа… пользователей делят не по таблицам а по группам!
Таки салюшен начинается с нефункциональных требований про них не сказано ничего или вскользь. Сколько пользователей, сколько курьеров, где разворачиваемся (aws, azure, ), надежность, доступность, как и кто поддерживает после релиза и прочее. Без этого проектировать бессмысленно. Есть очень хороший плейлист у Interview Pen так и называется system design.
Мне ещё нравится канал System Design Fight Club. Но моё видео немного не про это, а про ход мыслей при проектировании бизнес логики и компонентов пет-проекта на тему доставки еды. На эту тему нужно в начале видео озвучивать дисклеймер, спасибо за комментарий.
Мне кажется, что прямоугольник рест апи должен быть не параллельным, а последовательно включен в три параллельные сущности потому что он функция этих трех аргументов . Или нет !?
Я сразу скажу, что новичок. Но меня запутала тема про появление delivery совсем. На плане проектирования сущностей Delivery не было, разве по REST API не надо было проектировать что-то вроде обновления статуса заказа, то есть PATCH /order/${id} с передачей статуса как вы делали в одном из методов Restaurant API ? За видео спасибо, годное. Успехов
Спасибо за отклик. Полную диаграмму сущностей я не показывал, сконцентрировался на статусах заказа и том, как заказ меняется внутри системы в процессе оформления, приготовления, доставки. Идея REST API доставки в том, что мы работаем с сущностями из предметной области доставки. Например, метод приёма доставки в работу курьером - `POST /delivery/${id}`. Сервис, обрабатывающие этот запрос, работает с сущностями "delivery", который связаны с сущностями "order" (заказы). Приём delivery курьером в рамках описанной архитектуры приводил бы к тому, что delivery-rest-api сервис изменит статус заказа на `DELIVERY_PICKING`. И хочу заметить, что в реальности многие аспекты придуманного дизайна очень сильно бы изменились. Видео не про готовый дизайн, а про процесс проектирования и ход мыслей.
Сергей, спасибо за видео! Вы применяете необычные верхнеуровневые нотации. Могли бы подсказать, подобный формат описания API - по какой-то спецификации или свои наработки?
Добрый вечер. Подобной формой записи пользуюсь для себя на ранних стадиях продумывания схемы эндпоинтов. Когда приходит время формализовать схему, пользуюсь форматом спецификации OpenAPI.
В какой backend service поместить таблицы order и order_items? Целесообразно ли создать лучше новый сервис orders и помещать все сущности касательно заказов
Не надо бить на микросервисы если у вас нет команды чтобы поддерживать интерфейсы консистентными, писать end-to-end тесты и прочее дерьмо. К тому же в 95% случаев ваш стартап загнется раньше чем ему понадобятся микросервисы.
Не очень нравится табличка orders, думаю, следует в табличку orders добавить общую цену заказа, так как общая стоимость может не равняться стоимости всех товаров в корзине, могут быть модификаторы на общую цену в зависимости от количества или действующих акций. Да и сами цены, по уму, на каждую позицию по предметной области должны храниться в отдельной таблице, так как стоимость в каждый временной промежуток является частью публичной оферты.
Зачем всем сервисам иметь доступ ко всем базам? Зачем тогда вообще разделять бд?SQL не справится с сохранением токенов? Есть неугасимое желание поддерживать больше инфраструктуры? Еще я бы использовал ролевую модель и после определения роли отправлял бы юзера куда надо. А в остальном прекрасный вводный гайд, спасибо. Было интересно
Привет. Начать карьеру можно и на C# и на Java, принципиальной разницы нет. Результат будет определён другими факторами, а не выбором языка. Писал про это статью - t.me/zhukovsd_it_mentor/86.
Трудно посоветовать что-то конкретное, потому что видео затрагивает по верхам несколько разных тем, но постараюсь: - Проектирование бизнес логики - Domain Driven Design by Eric Evans - Паттерны проектирования архитектуры (бесплатная книга) - get.oreilly.com/rs/107-FMS-070/images/Software-Architecture-Patterns.pdf - Проектирование БД - SQL Antipatterns by Bill Karwin - Проектирование API - REST API Design Rulebook by Mark Masse
Бро, спасибо за контент, я джун и мне очень интересно. Вопрос - что если завести price_history где хранить все исп. скидки / наценки по позиции, а в ордере хранить уже итоговую стоимость ? Видел на проекте discount и price, которые вообще непонятно как формировались (можно было разобрать только по логам). И еще один - хранить деньги в копейках, а кол-во в x1000 это тру подход ?)
Получился бы слишком объёмный проект. Я спроектировал проект попроще, а студенты реализовали: - Проектирование - ruclips.net/video/vI9KEs9FsHY/видео.html - Разработка - ruclips.net/video/LLaJgrP6S1A/видео.html
Why would I need message broken for microservices to talk to each other? Stick them in the same network, let them talk through each other through REST API. Rather leave message broken for async work in order to not slow down UI.
почему РЕСТ, а не грпц скажем? зачем ресторану мобилка, повар с телефона должен заказы принать? чем обосновано раздение бекенда на три компоненты? отдать дань микросервисной моде, которая в данном примере нахрен не вписалась? бессмыслено и беспощадно разделить одну точку сбоя на четыре? чтобы втащить брокер без которого можно было обойтись? вообще в комментариях заявлено "ход мыслей", но основной ход мыслей был оставлен за кадром.
Более долгая реализация и имплементация, чем rest. Внедрение простой службы grpc занимает около 45 минут. Реализация rest api занимает всего около 10 минут. Связано это по большому счёту с отсутствием встроенной поддержки в сторонних инструментах
@@tetsuya9158 чушь написал. вопервых 10 минут и 45 минут это время одного порядка. во вторых если делать рест по человечьи через опискание на ямле и кодогенерацию сваггером, то будет не быстрее чем грпц.
@@mihax56 rest api в любом случае пишется быстрее, потому что имеется больше инструментов для его встроенной поддержки. Из-за чего небольшой учебный проектик легче / быстрее продемонстрировать с его использованием
@@tetsuya9158 давай закончим тем, что выбирать рест, грпц или чтото другое на основании "легче пишется" это крайне тупорылый подход, который в реальной жизни не применяется.
Спасибо за информативное видео. Хотел уточнить как будет вызываться REST Api после попадания сообщения в очередь RabbitMQ. Как я думаю, если это клауд то в RabbitMQ мы пишем например Azure function (AWS lambda) которая будет триггериться входящим сообщением и дальше будет вызываться соответствующий REST Api? А если это не в клауде то придется писать свой листенер для очереди?
Вариантов много, и они зависят от нефункциональных требований к продукту, особенно от требований к стеку и выбору облачного вендора, требованиям к бюджету на эксплуатацию продукта.
Диаграммы из видео - t.me/zhukovsd_it_chat/8867
По больше таких стримов, Kotlin, Python, Rust - все и так изучают, а вот правильное проектирование и системный дизайн это то, чего так не хватает. Спасибо )
Этому учат в ВУЗах, а еще книжки попробуй тематические почитать
вообще поподробней хотелось по этой теме. Особенно об инструментах
@@vincentvince2136 В книгах тоже много теории, нужен сам процесс.
где вы тут увидели про проектирование и дизайн? )))
сначала до уровня хотя бы мидла дорасти, а потом грязными ручонками лезь в архитектуру.
Первый раз смотрю подобное видео - случайно попало в рекомендованные. Очень интересно было посмотреть и понять ход мыслей разработчика при работе над проектом.
Я как маркетолог часто слышал обрывки диалогов программистов и теперь более понятно о чем идут столь оживленные дискуссии )
Ну и, по правде говоря, при работе над улучшением продукта, мне реально интересно знать как этот продукт устроен технически. Теперь ясно как в целом работает приложение.
Было бы интересно в таком же формате разбор от ПМа, продакта и бизнес аналитика.
P.S. Кому нудно - включайте на х1,75. Отлично смотрится.
Более содержательного видео не могу вспомнить, пусть поверхностно, но за полтора часа дать такое комплексное описание целого, почти реального проекта, это просто вау, что самое главное понятное. Премного благодарен автору, подписка однозначно.
нашел это видео после после просмотра видео о каналах шизофреников
😅😅😅
Жесть, ну там конечно и клоуны 🤡
Да у меня тоже они всплывают. Хотя никогда не кликал
Точно также тут оказался
Что за каналы такие? Очень интересно.
Почитал комментарии и аж обидно стало. Видео просто пушка. Автор сразу же обозначил цель видео, наложенные ограничения и в чём вообще задумка и мне кажется, автор цели достиг, с задачами справился и ограничения учёл.
Видео, на мой взгляд, получилось очень информативным, полезным и интересным. Процесс проектирования сложных сервисов действительно показан хорошо. Даже если бы обсуждался реальный сервис - уже было бы от чего оттолкнуться и что начать обсуждать командой из нескольких человек, а не в одно лицо. Такой результат за полтора часа - это очень круто(понятно, что автор потратил больше, чем полтора часа, рисование схем, продумывание сценариев - это довольно много времени, но всё же). Да, много моментов, которые просят пояснения, много где можно подискутировать и поспорить, но видос не про это вовсе.
Сергей, большое вам спасибо! С дикцией у вас тоже всё отлично, да и в конце концов, вы не теледиктор, вас не за красоту слога приходят смотреть.
Спасибо 👍
@@zhukovsd_it_mentorвидео класс, продолжайте в том же духе
Огромное тебе спасибо, Гэри Олдман, за прекрасное изложение материала ещё и на русском. Посмотрел за раз, не отрываясь. Успеха тебе в ютуб-пространстве.
На редкость полезное видео. Дизайню интерфейсы, чисто из любопытства решил поинтересоваться за архитектуру - теперь всё прям по полочкам расставилось. Спасибо.
Спасибо, посмеялся.
Классическая ошибка "микросервисы ради микросервисов", аналогично redis и rabbitMQ. Аналогично столь подробное планирование архитектуры простого проекта.
При этом нет обоснования выбора того или иного пути.
Согласен. Вместо одного большого монолита мы сделаем кучу сервисов, которые юзают одну и туже бд. По сути получился распределённый монолит, с кучей побочных проблем: deploy, масштабирование, сомвестимость api
Вы всё верно пишете, но задачи спроектировать коммерческий проект я для себя не ставил при подготовке к этому видео. Цель видео - озвучить ход мыслей, и схематично показать процессы проектирования. Основная моя ЦА - джуниоры и те кто готовится к своей первой работе, я стараюсь чтобы понятность моего контента соответствовала целевой аудитории.
Вопросы монолита и микросервисов, очередей и прочее - вопросы более высокого уровня, для понимания и обсуждения которых нужен определённый уровень и опыт.
Но так как на канал приходят люди с таким опытом, как вы, например, постараюсь в будущем делать более явный дисклеймер на эту тему.
Спасибо за фидбек.
@@radik353 очень странный подход - показывать именно формально бюрократическую часть работы, гиперболизируя её и не объясняя логики. Ну да бог вам судья
@@zhukovsd_it_mentor Я пропустил в этом видео момент где вы хоть что-то проектируете. Укажите таймкод, пожалуйста.
@@mightybobka 1:39:41
Спасибо, очень любопытно посмотреть как этим занимаются на практике. Я и сам учусь на программиста самостоятельно и понимаю, что самое главное в этом деле - архитектура. Это - начало начал и именно этим мне и нравится заниматься, нежели кодингом. Изучил немного тему EDA, событийно-ориентированной архитектуры и DDD, предметно-ориентированный дизайн приложений. Считаю, что это лучшая связка для архитектуры практически любых приложений, так как события убирают связность между модулями, а предметные области позволяют правильно разбить приложение на отдельные службы.
У вас разбивка похожа на DDD, но отличие в том, что у вас все данные хранятся в одном месте, что противоречит DDD. По DDD каждая служба (сервис) должна хранить свои данные в своей независимой базе (теоретически СУБД можно использовать одну, но базы должны быть разные). По DDD каждая предметная область содержит как данные, так и логику для их обработки (по сути как и объект в ООП), что создаёт изоляцию и независимость от других предметных областей. А это даёт больше свободы и простоты в поддержке. Можно любую предметную область удалить, добавить, и это будет абсолютно не заметно для других, если используются события для общения, а не прямые RPC и прочие такие запросы с ожиданием ответа. При чисто событийной архитектуре всё общение идёт через шину событий, и она является единственным модулем, с которым напрямую связаны все предметные области. А это - максимальная изоляция друг от друга - то, к чему стремятся многие программисты, понимая весь ужас и тяжесть монолитных и спагеттеобразных приложений, где все связи между модулями и данными прямые.
Не лучше ли всё-таки использовать DDD?
Согласен с вашими рассуждениями о ценности DDD.
В этом видео моей целью было по продемонстрировать ход мыслей при проектировании и наглядно по верхам показать схемы, БД, API.
Но проект я выбрал довольно сложный, плюс, полтора часа - и так уже много, поэтому местами вышло поверхностно.
В последующих видео по проектированию стараюсь не повторять эти ошибки.
Это действительно важное принципиальное замечание, т.к. если уж упомянули о микросервисной архитектуре, то надо придерживаться и требований к микросервисам (у каждого свои данные). Иначе для тех, кто только начинает постигать системный анализ это может надолго создать неправильный подход.
Огромное спасибо. Очень интересно, а главное, доходчиво получилось. Для меня как будто открылся закулисный мир разработки.
Было очень интересно послушать по архетектуру и технологии. Спасибо за интересный материал! Успехов вам!
Офигенный материл! Побольше бы таких с аргументированными объяснениями подходов.
Спасибо тебе, Гэри Олдман, за видео!
Еще не смотрел полностью но кликнув на середину уже офигел от качества!!! Гляну попозже, поддержу сейчас!
Гениальный видос, ничего подобного не видел за время активного поиска обучающего материала!
Это что-то конечно..случайно наткнулся на это видео и буквально залип. Огромное спасибо автору за очень ценный урок и прекрасное, доходчивое объяснение!
Ашалеть, теперь и Гари Олдман в разрабах)
Содержательно, без воды. Есть понимание что и как надо осваивать, после того как разобрался с "Hello world" :D
Проходили про базы данных в вузе, про бек и фронт - на тестовых заданиях в ШМЯ. А вот про API не знала, это было новым. Спасибо! Это круче, чем онлайн курс.
Круто, очень полезная информация!
Рад за автора, что он прочитал книгу "Микросервисы на практике"
Шел 2023й, мы выкладывали видео по программированию в 720p... Впрочем, спасибо за материал.
Спасибо, крутое видео, не каждый выкладывает структуру реального проекта и процесс проектирования. Вроде простое приложение, но офигеть насколько сложной схема получается, и это без всяких нюансов и общепринятых каких-то дополнений.
Спасибо за отзыв.
Всё-таки это не архитектура реального проекта, а скорее упрощенная демонстрация хода мыслей, с которыми подходят к проектированию.
Очень многое не рассмотрено, но и так полтора часа получилось.
отдельно понравилось рассуждение
"ну сейчас все делают микросервисы поэтому мы тоже сделаем их"
чевооооооо
с ровного места огромные оверхеды разработки добавлены
Ни разу не делал схемы и не знал как они делаются. 3 года уже пишу свои проекты просто на абум, замотивировали почитать книжки по проектированию
наобум
Спасибо большое за такую полезную информацию!
Спасибо за проделанную работу!
Спасибо за качественную информацию!
На троечку конечно аналитика и проектирование
Ну хоть на троечку 🙂
В таблицу Orders я бы добавил не одно поле timestamp, а что-то типа created и delivered - дата создания заказа и его доставки. Также можно было бы добавить таблицу а-ля "Order_Rating" со связью по полю id таблицы Orders, где была бы оценка заказа и комментарии по нему.
Пока что отсмотрел не всё, но очень интересное видео. Показывает как можно и на что разбить проект, чтобы дальнейшая разработка шла по сформированной программе. И самое главное, что это прямая трансляция, где всё происходит без вырезания некоторых сцен(хотя понятно, что вопрос рассматривался ранее и рассматривались разные варианты).
Очень интересно. Спасибо!
Спасибо. Очень полезная информация. На кого же похож автор. Мне кажется на Жан Батист Эммануэль Зорг - вымышленный персонаж, главный злодей научно-фантастического фильма Люка Бессона "Пятый элемент". Сыгран знаменитым британским актером Гари Олдманом. )
Да,гари вообще играет нормально во всех фильмах,понравилась его роль в фильме - книга иллая.
Смесь Тодда Говарда и Мэрлина Мэнсона
Научился по этому видео зарабатывать воображаемую зарплату!)
Рад помочь 👨💼
Блин классно. Единственное для новичков хотелось бы видеть полноценную ER диаграмму
Супер, очень крутой стрим)
видео с мелким текстом в 720p
Гениально
Очень крутое видео! Увидеть бы реализацию)
мы с пацанами расходимся после катки
так же тот самый чел который решил рассказать коротенькую схемку с большой прибылью:
Спасибо! Хотелось бы подробнее про аутентификацию, авторизацию, логирование, метрики, балансировку нагрузки и т.п.
Здравствуйте, спасибо большое, это очень круто!
Хочется больше таких видео! Вы супер, у Вас всё обязательно получится!!
Хорошее видео. Больше таких. )
интересная информашка. буду в бедующем наверное рассуждать по твоему же принципу.
Спасибо! Побольше бы такого годного контента на ютубе
25:11
Интересный подход, вроде все просто но раньше не приходило такое в голову, спасибо.
Получается помесь BPMN и проектирования, на чистом BPMN конечно сам процесс был бы более качественно описан, но зато в таком виде удобно изучать архитектуру.
В работе постоянно есть выбор между "обобщить" и потерять часть информации или "детализировать" но в итоге перегрузить схему так что она становится не читаемой. Вам удалось соблюсти хороший баланс. Это тоже важный навык который требуется нарабатывать.
Спасибо, в этом и была идея, не перегружать слушателей терминологией, но при этом озвучивать ход мыслей по проектированию.
@@zhukovsd_it_mentor тебе спасибо за видео, для меня это новый мир особенно те видео где ты разбираешь проекты, то как искуссно ты говоришь о недостатках при этом не обижая людей но в то же время конструктивно это что то недостижимое.
Я сам по работе лид и делаю ревью кода Джунов и мидлов и приходится так же общаться с людьми, естественно я стараюсь быть минимально токсичным, но по сравнению с тем как ты это делаешь Я просто ребенок)). Очень много полезных приемов общения у тебя увидел.
Писать код на самом деле самое простое что есть в работе Лида. Самое сложное это давать обратную связь и уметь явно излагать свои мысли.
Если это читают начинающие ребята то мой совет учитесь у этого человека излагать мысли это гораздо важнее умения писать код)))
@You2Ber42 спасибо, очень приятно что кто-то понял ровно то, что я пытаюсь донести в ревью между строк
Видео супер, в качестве обучаеющего материала для разного уровня специалистов, спасибо автору за проделанную работу!!
я - весьма токсичный и нередко гажу в комментах (борюсь с этим, но не всегда получается). А это видео - тот случай, когда хочется поблагодарить автора за проделанную работу!
Человек, который честен себе
просто находка! вы очень крутой
Приложение вкусвилл идеальное во всей планете берите пример
Надо учесть ещё возможность получения отчетов как из платежного сервиса, так и гибридных когда в одном отчете информация из всех серверов и сервисов.
И логирование всего и вся
Классный ход мысли. Видно, что много раз делали подобный дизайн. Интересно, можно ли получить подобный ход мысли на синтетических задачах проектирования?
Как и со многим другим, это вопрос опыта. Помогают книги по проектированию, эксперименты с пет проектами, участие в проектировании рабочих проектов.
@@zhukovsd_it_mentor какие книги посоветуете? И есть ли реальный от них прок в понимании архитектуры?
@Jilexa
Самое главное - в рабочих проектах учиться у старших коллег и постепенно участвовать в проектировании.
По книгам:
- Проектирование бизнес логики - Domain Driven Design by Eric Evans
- Software Architecture Patterns
- Если в проекте есть БД, SQL/NoSQL, хорошо почитать что-то про проектирование хранилища, например книгу "SQL Antipatterns"
Спасибо , бро. Очень Полезная информация.
Очень полезно и интересно, будет ли продолжение
Практическая реализация этого проекта не планируется, идея видео - описать ход мыслей при проектировании.
Но мне интересно было бы продолжить эту серию видео, спроектировав что-нибудь ещё, поэтому буду рад услышать предложения.
Я сейчас прохожу обучение по джама, скоро присаединусь
@@zhukovsd_it_mentor p2p обменник,
@@user-rv9ss5ce7z да, p2p актуально
Супер классное видео!
Спасибо, очень интересно
Спасибо, очень хороший разбор
In some food delivery services, the courier get firstly the order and go to the restaurant and wait then get the order,
Просто отлично!
Соо миллионов лайков Тебе, дорогой!
Бальзам для ушей
Спасибо мужик.
просто кайф, спасибо!
Спасибо, очень крутой high-level обзор! Как раз то, что искал для постепенного перетекания в fullstack
А с каких пор фул стек пишет высоконагруженные системы?
Мне кажется, те требования, которые не будут реализованы сейчас , они все равно должны быть отмечены как подпроцессы.
Интересное видео, узнал для себя пару новых вещей
Остановил ролик после проектирования бд. Очень поверхностное проектирование вообще при довольно сложной темы как агрегатор доставки еды. А номер позиции в меню? А категория блюда? А правила для заказа (минимум ценик заказа, расстояние между клиентом - рестораном )? А возможность убрать ингредиент? А если сеть ресторанов? А как сама агрегация ресторанов будет происходить? А возможность отзыва? и тд тп... уж лучше сделали подробно онлайн заказ у одного ресторана.
ТЗ уровень описания того самого клиента на фриланс платформе, который не понимает что хочет и ничего толком не знает (сто пудов кинет и у него будут круглые глаза когда узнает сроки\цену). Ну и хранение постоянно меняющееся coorinates курьера в холодном хранилище, даже теоретически, конечно убило.
Замечания по делу, спасибо 👍
Спасибо большое
Мощный видос!
Случайно попал на видео, у заказа нужны свойства(уже стандарт) свойства заказа могут быть разного типа… пользователей делят не по таблицам а по группам!
Круто 👍🏻
позновательный контент благодарю
Таки салюшен начинается с нефункциональных требований про них не сказано ничего или вскользь. Сколько пользователей, сколько курьеров, где разворачиваемся (aws, azure, ), надежность, доступность, как и кто поддерживает после релиза и прочее. Без этого проектировать бессмысленно. Есть очень хороший плейлист у Interview Pen так и называется system design.
Мне ещё нравится канал System Design Fight Club.
Но моё видео немного не про это, а про ход мыслей при проектировании бизнес логики и компонентов пет-проекта на тему доставки еды.
На эту тему нужно в начале видео озвучивать дисклеймер, спасибо за комментарий.
Супер!
Мне кажется, что прямоугольник рест апи должен быть не параллельным, а последовательно включен в три параллельные сущности потому что он функция этих трех аргументов . Или нет !?
Спасибо.
Мне кажется проектирование нужно начинать с логической модели приложения. Все остальное должно после нее проектироваться. Ну как минимум так проще.
круто
я 9 минут и 45 секунд ждал начала
Почему отношение Order_Items к Menu_items - 1:1, а не n:1 ? Одна позиция меню может участвовать во многих заказах. 43:07
Идея в том, что цена и количество конкретного товара может отличаться от заказа к заказу, поэтому 1:1
Я сразу скажу, что новичок. Но меня запутала тема про появление delivery совсем. На плане проектирования сущностей Delivery не было, разве по REST API не надо было проектировать что-то вроде обновления статуса заказа, то есть PATCH /order/${id} с передачей статуса как вы делали в одном из методов Restaurant API ?
За видео спасибо, годное. Успехов
Спасибо за отклик.
Полную диаграмму сущностей я не показывал, сконцентрировался на статусах заказа и том, как заказ меняется внутри системы в процессе оформления, приготовления, доставки.
Идея REST API доставки в том, что мы работаем с сущностями из предметной области доставки. Например, метод приёма доставки в работу курьером - `POST /delivery/${id}`. Сервис, обрабатывающие этот запрос, работает с сущностями "delivery", который связаны с сущностями "order" (заказы). Приём delivery курьером в рамках описанной архитектуры приводил бы к тому, что delivery-rest-api сервис изменит статус заказа на `DELIVERY_PICKING`.
И хочу заметить, что в реальности многие аспекты придуманного дизайна очень сильно бы изменились. Видео не про готовый дизайн, а про процесс проектирования и ход мыслей.
Курьеры работают за "profit" :D
Сергей, спасибо за видео! Вы применяете необычные верхнеуровневые нотации. Могли бы подсказать, подобный формат описания API - по какой-то спецификации или свои наработки?
Добрый вечер. Подобной формой записи пользуюсь для себя на ранних стадиях продумывания схемы эндпоинтов.
Когда приходит время формализовать схему, пользуюсь форматом спецификации OpenAPI.
В какой backend service поместить таблицы order и order_items? Целесообразно ли создать лучше новый сервис orders и помещать все сущности касательно заказов
Не надо бить на микросервисы если у вас нет команды чтобы поддерживать интерфейсы консистентными, писать end-to-end тесты и прочее дерьмо. К тому же в 95% случаев ваш стартап загнется раньше чем ему понадобятся микросервисы.
В основном делаю( pet project)фронт на жабе используя API сервера,в бэк боюсь лесть 😂😂думаю там намного логика сложнее.
Для тестировщиков тоже полезно будет
Не очень нравится табличка orders, думаю, следует в табличку orders добавить общую цену заказа, так как общая стоимость может не равняться стоимости всех товаров в корзине, могут быть модификаторы на общую цену в зависимости от количества или действующих акций. Да и сами цены, по уму, на каждую позицию по предметной области должны храниться в отдельной таблице, так как стоимость в каждый временной промежуток является частью публичной оферты.
Зачем всем сервисам иметь доступ ко всем базам? Зачем тогда вообще разделять бд?SQL не справится с сохранением токенов? Есть неугасимое желание поддерживать больше инфраструктуры?
Еще я бы использовал ролевую модель и после определения роли отправлял бы юзера куда надо.
А в остальном прекрасный вводный гайд, спасибо. Было интересно
Скажи пожалуйста, что лучше выбрать для начала карьеры в данный момент C# (.NET) или Java (Spring) ?
Привет. Начать карьеру можно и на C# и на Java, принципиальной разницы нет.
Результат будет определён другими факторами, а не выбором языка. Писал про это статью - t.me/zhukovsd_it_mentor/86.
Полезное видео, посоветуйте литературу по этой же тематике
Трудно посоветовать что-то конкретное, потому что видео затрагивает по верхам несколько разных тем, но постараюсь:
- Проектирование бизнес логики - Domain Driven Design by Eric Evans
- Паттерны проектирования архитектуры (бесплатная книга) - get.oreilly.com/rs/107-FMS-070/images/Software-Architecture-Patterns.pdf
- Проектирование БД - SQL Antipatterns by Bill Karwin
- Проектирование API - REST API Design Rulebook by Mark Masse
@@zhukovsd_it_mentor Спасибо!
а почему только 720 ? Не видно нечего ((
Моя ошибка. Более свежие видео в 1080p
@@zhukovsd_it_mentor спасибо!
Бро, спасибо за контент, я джун и мне очень интересно. Вопрос - что если завести price_history где хранить все исп. скидки / наценки по позиции, а в ордере хранить уже итоговую стоимость ? Видел на проекте discount и price, которые вообще непонятно как формировались (можно было разобрать только по логам). И еще один - хранить деньги в копейках, а кол-во в x1000 это тру подход ?)
9:50 Начало
Очень хочется увидеть реализацию этой схемы! Чтобы был понятен полный цикл разработки
Получился бы слишком объёмный проект.
Я спроектировал проект попроще, а студенты реализовали:
- Проектирование - ruclips.net/video/vI9KEs9FsHY/видео.html
- Разработка - ruclips.net/video/LLaJgrP6S1A/видео.html
А чо UML уже отменили???
Why would I need message broken for microservices to talk to each other? Stick them in the same network, let them talk through each other through REST API. Rather leave message broken for async work in order to not slow down UI.
Thanks, that's a reasonable approach.
почему РЕСТ, а не грпц скажем? зачем ресторану мобилка, повар с телефона должен заказы принать? чем обосновано раздение бекенда на три компоненты? отдать дань микросервисной моде, которая в данном примере нахрен не вписалась? бессмыслено и беспощадно разделить одну точку сбоя на четыре? чтобы втащить брокер без которого можно было обойтись? вообще в комментариях заявлено "ход мыслей", но основной ход мыслей был оставлен за кадром.
Более долгая реализация и имплементация, чем rest. Внедрение простой службы grpc занимает около 45 минут. Реализация rest api занимает всего около 10 минут. Связано это по большому счёту с отсутствием встроенной поддержки в сторонних инструментах
@@tetsuya9158 чушь написал. вопервых 10 минут и 45 минут это время одного порядка. во вторых если делать рест по человечьи через опискание на ямле и кодогенерацию сваггером, то будет не быстрее чем грпц.
@@mihax56 rest api в любом случае пишется быстрее, потому что имеется больше инструментов для его встроенной поддержки. Из-за чего небольшой учебный проектик легче / быстрее продемонстрировать с его использованием
@@tetsuya9158 давай закончим тем, что выбирать рест, грпц или чтото другое на основании "легче пишется" это крайне тупорылый подход, который в реальной жизни не применяется.
@@tetsuya9158 и да, баран, порядок - это математическая степень величины - знаешь там 10 во второй или в в пятой бывает, так что утрись.
Спасибо за информативное видео. Хотел уточнить как будет вызываться REST Api после попадания сообщения в очередь RabbitMQ. Как я думаю, если это клауд то в RabbitMQ мы пишем например Azure function (AWS lambda) которая будет триггериться входящим сообщением и дальше будет вызываться соответствующий REST Api? А если это не в клауде то придется писать свой листенер для очереди?
Вариантов много, и они зависят от нефункциональных требований к продукту, особенно от требований к стеку и выбору облачного вендора, требованиям к бюджету на эксплуатацию продукта.
топ контент
как найти ещё такие видео или контент?