НЕ ООП ЕДИНЫ! Domain Driven Design на примере ХОЛОДИЛЬНИКА / Tech Lead Борис Беньковский 

Ну какое нафиг Symphony? Symfony, SYMFONYYYYYYYYYYYYYYYYYYYY

@@devracoon да всем похер на пыху)

@@itbeardобидно, но нет, я пхпшник 7 лет, симфони 5 из них, еще с 1 версией работал... В жопу пхп, сейчас на голанг и котлин 👍

A SSSSSS S SSSSSSSS SSSSSSSSSSSSSSESSIONSSSSSSSSSSSSßßSSSSSSSSßSSSSSSSSSSSßSSSSSSSSSßSßSßßSSSSSSSSßSSSßSSßSSS SSSßSßSßSßS S

ахахах, весь выпуск думал, кого же он мне напоминает

Зашёл посмотреть на такой комментарий

Поперечный XL

Пригожин отрастил бороду и тоже начал вникать

Чуть чуть похож реально

У него чёрный пояс по гастрономическим метафорам

Судя по пузику Лекса, он тоже не отстает

@@smookkee1 самое лучшее пузико на этой планете!

Ты Service)

вот вы объяснили лучше, чем спикер за все видео

Вот. Сразу чувствуется структурное мышление

Домен - это вся пиццерия. Отделы - это bounded context.

@@timur43378 bounded context это бухгалтерия, рецепты, табель, меню. Для начала в терминах разберись

Это индикатор понимания, причина почему полезно не только учится но и учить.

А все потому что эта сложная тема еле натягивается даже на простой пример. А на реальном сложном бизнесе придется в эти доменные сущности инжектить по 50 сервисов со всеми вытекающими проблемами с производительностью общения с базой.

@@valeravalera6201 поверьте, когда идут реальные примеры, все в разы проще, это в 100 раз проще понять когда у тебя просто микросервисы есть, а не какой-то монолит с одинаковым классами "Холодильник" которые лежат в разных модулях/неймпейсах. Любая ссылка про ДДД в гугле, намного понятнее это все поясняет, уверен гость понимает о чем говорит, но выбор "Холодильник + Монолит" объективно неудачный.

спасибо!

Call to a member function getKolbasa() on null

@@vesh95 В голос 🤣🤣🤣

Ее лучше на английском читать, перевод там ужасен

"The single-responsibility principle (SRP) is a computer-programming principle that states that every module, class or function in a computer program should have responsibility over a single part of that program's functionality, and it should encapsulate that part." (c) Wiki Согласен, что "single part of that program's functionality" понятие не очень конкретное - границы part весьма условны, нет единого стандарта. Принцип помогает определить при проектировании сущности её будущую зону ответственности и при необходимости снижать функциональную "нагрузку". Я к тому, что принцип желательно использовать уже на этапе проектирования, иначе на этапе изменений могут возникнуть трудности 🙂

собственно Ваш ответ и иллюстрирует озвученную проблему с S - можно бесконечно спорить отвечает ли класс этому принципу, и при этом каждая из сторон спора будет по-своему права. "Одна причина для изменений" согласно теории - правильное определение, только в реальности, применительно к реальному классу написанному без какого-либо DDD и с соблюдением священного SOLIDа это можно трактовать по-разному. Кончается спор на code review как правило на том, что одна из сторон просто понимает, что продуктивнее будет просто перестать тратить время на бесполезный спор, согласиться с собеседником и идти дальше.

@@AlexS-gn9tq алюминь, брат. Постоянно с этим сталкиваюсь. И в плане споров это вообще топ. Самая боль когда приходится доказывать такому же синьёру-сениору что пихать валидацию, нотификацию, сбору объекта, логирование и созание платежа в сервис CreatePayment не есть гуд. Потому что с его точки зрения все эти процессы часть одной бизнес-логики - созания платежа. По своему опыту заметил что обычно таких вопросов будет меньше если начинать писать сервис с тестов, интефейсов и по принципу минимальной необходимости. То есть, если нужен валидный объект в сервисе то ты можешь либо сразу передать его (или получить) в сервис. И тогда никакой валидации не будет в принципе. Либо писать метод (возможно приватный) который будет собирать этот обьект и не дай бог там будет логика и значит тратишь время на тест и тут же можешь себя отрефлексировать что возможно это ответственность другого сервиса.

@@kinvain Я сейчас как раз на этапе, когда логика лежит в классе сервиса - как вы и описали на примере создания платежа. Я ментально понимаю, что здесь идет перемешивание, но пока это проще поддерживать, чем держать в контроллерах, но вы могли бы привести пример, как это концептуально должно быть? Например, сейчас это так PaymentService { create(creatorId, amount):Payment { this->transaction->start(); user = this->userStore->getExistent(creatorId) this->validator->validate(form = new CreatePaymentForm(creatorId, amount)) payment = Payment::new(form->creatorId, form->amount, user->id); this->paymentStore->save(payment) this->logger->createPayment(payment) this->notification->notifyCreatePayment(payment) this->transaction->end(); return payment; } } Логирование и нотификация должны срабатывать через события? Как это разносить. В данном случае, store - он просто сохраняет в бд модель activeRecord.

@@artemvolt4600 чисто интуитивно я бы предложил следующее PaymentService::create получает только те данные, которые нужны для созднаия платежа. А именно не creatorID и amount, а сразу объект типа Payment. И объект этот сразу должен быть валидным. То есть вы сначала собираете форму, в контроллере, например, валидируете её, создаёте объект платежа и дальше передаёте его в сервис создания. Выигрыш будет в том что когда вы захотите создавать платежи не только через web-страницу, но ещё и через API, а потом ещё напишете консольную команду, то единственное что будет отличаться - как собираются объекты Payment. Создание же будет всегда одинаковое PaymentService::create() Сделать интерфейс PaymentCreator с одним методом - create(Payment) и реализовать его для 1) непосредственно сервис создания платежа 2) логирование 3) нотификация. Дальше вы можете сделать стэк из этих сервисов (паттерн Декоратор) и каждый сервис будет заниматься только своим и вызывать следующий сервис. Например, PaymentCreateLoggerService будет логировать начало обработки, вызывать сервис создания, логировать результа (например, если было брошено исключение). Но логирование это вообще отдельная боль... Особенно когда приходится раскуривать логи и искать нужное. Нотификацию я бы предложил сделать через событие. PaymentService сохраняет платёж и делает какой-нибудь dispatch(new PaymentCreated($payment)). И добавить в систему слушатели этого сыбития для желаемого поведения. Я понимаю что это больше псевдо-код, но предложил бы делать конекретные сервисы. PaymentService - не понятно что он будет делать. Созадавать? Обноволять? Удалять? PaymentDeleteService - сразу понятно. И если кто-то захочете добавить в него метод по обновлению платежа то как минимум задумается. Моя идея в том что бы сервисы работали только с бизнес-объектами. Payment, к примеру, это бизнес-объект. А вот форма - нет. Потому что сегодня вы используете Symfony, а завтра решите переехать на Laravel реквесты. Такого, конечно, не будет, но смысл в том что бы вы могли написать свервис не думая о фреймворке и базе,

Досмотрел до этой точки ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-rkQ3-T82pkU.html , главную ответственность сервиса упомянули.

Но по хорошему два агрегата обновлять два агрегата в одном сервиса эта идея уже с запашком. Так как в первую очередь она не масштабируема, сложно переносима между между типами баз данных, например на реляционной базе данных этот пример будет работать, а в MongoDB уже его придётся переписывать, так как там нет транзакций между коллекциями документов. Вопрос как же быть в таком случае. Нужно определиться с какие у нас есть возможности баз данных, вот например, в MongoDB всё операции модификации атомарны на уровне документа. В реляционках есть транзакции. Теперь проводим черту между ними. Черта проходит ровненько через агрегат. Единственное что мы можем гарантировать для того чтобы система была консистента и масштабируема в одно и тоже время, так это атомарность агрегата на уровне апликешен логики. И тогда получается сервис как бы становится антипаттерном в данном случае. То есть проще как сказано выше просто из фабрики или репозитория дёрнуть агрегатСклад.вывезти() и сохранить агрегат в базу через репозиторий: репозиторийСклад.сохранить(агрегат склад). В методе сохранить будет конкретная имплементация под базу данных в MongoDB документ атомарен, а в SQL нужно будет создать транзакцию, если потребуется модифицировать записи из нескольких таблиц. В данном кейсе мы как пока решили ровно половину задачи выше касательно склада, назовем её левой ногой). Теперь нам нужно что-то решить с правой ногой то есть со списывание денег со счета пользователя. Пока без деталей применяем тот же подход что и для склада, ровно точно также. То есть у нас появляется правая нога. Обе эти ноги по отдельности они абсолютно масштабируемы, не зависисмы ни от базы данных, ни от фрейворков, чистая бизнес логика, которую можно и в браузере на JS запустить с in memory базой и на Lambda выполнить с бесконечным масштабированием, и протестировать, геркен тесты написать. Теперь есть выбор, можно раскидать эту логику в микросервисы, наносервисы, или оставить в монолите без изменения бизнес логики. Теперь остаётся самый важный этап как прикрутить две ноги к телу. Тут есть несколько вариантов, как по мне так мне ни один не нравится. Пример напишу в следующем коменте:

Варианты связки агрегатов, есть условие система должна быть масштабируема, но при этом есть другое условие, что атомарность мы гарантируем на уровне агрегата. В этом случае нам точно не подходят транзакции SQL, так как это привязка к типу базы, а так же это сразу блокирует масштабируемость. Нам не подходят по тойже причине распределеннные транзакции, то есть 2-3 фазные комиты. Единственный вариант на текущий момент, который можно прикрутить с довольно высокой степенью сложности реализации, так это асинхронное взаимодействие, тот самый event-driven development. Реализация вроде как проста, обычно виду два варианта, первый: пуляем ивенты в момент сохранения агрегата в базу или в очередь ивентов, а с другой стороны их обрабатываем. При такой асинхронной работе обычно нужно решать подзадачу, которая звучит так: "если уголь со склада вывезли (кинули ивент), но денег на счёте пользователя не хватило для оплаты, то верните (кинули ивент) пожалуйста уголь на склад". (То что в кавычках это и есть тот самый ubiquitous language, мы уже на нем общаемся если что 😀). Можно перефразировать: "отложите на складе 3 тонны угля для пользователя и когда пройдет оплата, то вывезите уголь со склада для пользователя." Вы поняли что у нас появились пара новых слов в нашем глобальном языке для агрегата склад: "отложить" и "вернуть". Как вы выберете будет зависеть от вашего бизнеса и требований. Теперь получается задача решена, но сложность системы повышена раза в 3. За счёт асинхронных компенсирующих операций. В этом примере есть на самом деле очень низкоуровневая проблема с самим процессом кидания ивента. Что если агрегат сохранился в базу, но сообщение не отправилось в очередь так как не было связи. Ну это уже отдельная тема.

Спасибо и удачи!))

Ещё был про с# и релокейт в Чехию позитивный гость)

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

Ку! Идея гуд, думали доску поставить. Но! Монтаж тогда будет совсем не очень, плюс ребята, которые в аудио слушают очень расстроится, а таких много.

Так что для старта пойдет, а дальше уже можно искать целенаправленно курсы😊

Согласен. Борис совсем не про DDD

Влад Хориков норм, смотрел его курс по DDD на pluralsight

Есть ещё Максим Аршинов

Тоже ловил себя на - да он же про 1с рассказывает :)

вообще не 1С. до 1С надо еще кучу абстракций сделать. и понять, что продукт не лажит в домене холодильника, а лежит в отдельном домене остатков по местам хранения. И нет у домена метода или контекста - взять продукт, или ремонт, а есть два домена `взять продукты из холодильника`, `ремонт холодильника`

DDD, как я понимаю, не обязательно про ООП. Стратегическая составляющая вообще про бизнес, аналитику и т.д. а тактические паттерны ничего не мешает и в процедурном стиле реализовать (к примеру)

Уже года как 2 есть трансляции

Полностью согласен

Не надо все грести под одну гребёнку, ТДД гораздо позже появился

в 2003 DDD примерно появился и TDD примерно тогда же.

@@bellmoon2754 "Автор" ТДД Кент Бек сам писал, что он переоткрыл эту идею, а не изобрёл её заново. И он ссылается на идею с перфокартами, которая описывает процесс ТДД.

@@ivan_lebedev DDD - это чистое объектно-ориентированное программирование. В нём новым оказывается позабытое старое, когда в 60х программисты знали предметную область и писали программы от неё отталкиваясь. В современном мире программисты абстрактные - они могут запрограммировать всё, но мало в каких предметных областях разбираются. И DDD напоминает, что вообще-то мы моделируем реальный мир и его конкретную часть, используя ООП.

> тут получается что все равно у нас будет достаточное количество логики в сервисах Все верно заметили. Да, я ошибся в том моменте, и чуть позже (в следующих фразах) постарался исправиться. Из RepairingService нужно вызывать ровно одну строку (без всяких дополнительных проверок - считайте нет логики) `KitchenService->cleanRefrigerator(Identity $id)`. Таким образом мы оказываемся в модуле кухни. Дальше уже в модуле кухни идем по стандартному пути (в зависимости от бизнеса) загружаем модельку (уже кухонную) и вызываем у этой модельки метод с бизнес логикой > мб базовый Refrigerator для таких вещей создавать? Если речь про abstract class то не стоит. Это нарушит разделение Bounded Context.

@@Biankouski Насколько ошибочно делать в модели холодильника вызов модели сыра? Условно "получить сыр, который находится в этом холодильнике".

@@hysapod Спросите у Бизнес Овнера. ДДД это про "записать код как в голове у людей, кто платит вам за этот код". Если в каком-то бизнес процессе нужно "получить сыр, который находится в этом холодильнике" - значит нужно получить сыр, который находится в этом холодильнике

@@hysapod крайне ошибочно. у модели (домена) холодильник не должно быть методов. в правильной вселенной: домен холодильник имеет свойства: режимы охлаждения, объем загрузки. домен сыр(продукт) имеет свойство объем упаковки домен остатков в холодильнике имеет свойства: ссылка на домен холодильник, ссылка на домен продукт, количество занятого объема, количество упаковок продукта домен действия `взять продукт из холодильника` имеет свойства: ссылка на домен холодильника, ссылка на домен продукта, количество упаковок продукта

Когда-то точно будет, раз 1с был) и сап ещё надо бы..

@@itbeard SAP koniecznie! :)

@@itbeard дааа Salesforce надо! говорят в Буларуси это самые "зажравшиеся" аутсорсеры, которые легко делают 3х-5х от среднего с девбай по стажу.

Спасибо!

А еще придется рассказать команде, что у нас личинка DDD, но никак не DDD )

На мой взгляд, можно читать только bounded context. Сам Эванс через цать лет после первой книги сказал, что это ключевая идея. И если писать вторую редакцию, то именно это будет центральной частью.

@@evgenyamorozov И Вон Вернон написал книгу именно с учетом этих мыслей)

Крайне рекомендую книгу Вон Вернона

пора бы переименовывать канал в АйТиПузико

Плюсую, тоже было бы очень интересно послушать)

Без задачи (цели\бизнеса) сложно сказать. Если задача - это редактировать теги в админке и навешивать по категориям\статьям, то Entity. Все всегда зависит от BoundedContext и решаемой бизнесовой задачи

Александр, а вы могли бы привести пример домена? Например, как ваш колета сделал новый домен, сформировал агрегат? Может от себя что-нибудь посоветуете, с чего начать для изучения этой темы?

> который зачастую имеет очень много зависимостей, даже на очень простых бизнес моделях) скорее всего у вас нарушается разделение Bounded Context. "зачастую" должно быть, что один агрегат (энтити с зависимостями другими энтитями) для одной задачи. Да, бывает что какая-то лишняя зависимость читается из БД, и при этом в бизнес логике на конкретном запросе не участвует (но и вызов в БД на сохранение не идет благодаря UnitOfWork), но единицы, а не "зачастую". > Можно конечно запилить exclusive lock То-ли я не понял вашу проблему, то-ли вы все проблемы смешали в кучу. Плюсы\минусы работы с транзакциями (и их типами) не отличаются от классической слоеной архитектуры. DDD это про то, как держать сложную бизнеслогику чистой (и от того понятной), в БД вроде как сложностей не добавляется. > Да и не очень понятно как это всё ложиться на REST API (где мы фокусируемся не на бизнесе модели, а на ресурсах, читай данных). 1. Если ваше API отлично ложится на RESTful (бекенд для SinglePageApplication админки) то скорее всего логики там и нет. Чекнул ACL да сохранил. Вам не нужен DDD. 2. Если ваше API маскируется под REST, при этом, например, за `PATCH /order/25 {orderStatus:processed}` скрывается туча логики, типо - заказ был в состоянии "в корзине", - теперь прилетело состояние "процессед" - значит это пользователь нажал кнопку "checkout" на корзине, - и т.д. то я могу предложить 3 опции (не зная всей вашей доменной области это будут "так-себе" советы, но попробую, в порядке приоритета): - для простых (crud) задач оставить RESTful и без ДДД, для задач "посложнее" обычный REST `POST /order/25/process` + DDD логика - вам не нужен RESTful вообще. Все технологии (и ДДД и Rest и PHP и Java) должны использоваться для упрощения жизни. Не упрощает - выбрасывайте. - добавлять какую-то прослойку\роутер маппинга RESTful запроса на ресурс на бизнес сервис. Условно пример выше " если пришел PATH с полем orderStatus значит CheckoutService->processOrder(25)" - RESTful бизнес моделей это "и есть ваш домен". Принять это как факт, и .. тогда вызывать сервисы вроде "OrderCrudService->patch(25)" ... выглядит, как первая опция самая адекватная :)

@@Biankouski спасибо большое, по REST API согласен, скорее его нужно использовать для внешних интеграций, в дополнение к DDD. По поводу работы с базой я имел ввиду следующее: вот есть холодильник, чтобы забрать продукт нужно чтобы его количество было больше нуля. Но мы ведь работаем со снэпшотом холодильника в какой то момент времени и к моменту сохранения его состояния в базу - кто то другой его уже проапдэйтит (забрав все продукты) и наша операция сохранения упадёт (если написана верно). Как обычно подобные кейсы хэндляться?

@@sergeymachel2278 по моему это головная боль менеджера модели, а не самой модели. Менеджер модели маппит данные из БД на модель. Пока вы что-то со своей моделью делали, кто-то изменил состояние данных в БД, теперь, перед обновлением этой записи, ModelManager должен об этом позаботится.

@@Zlobusz Окей, мы взяли снэпшот холодильника, отобразили на юае. Юзер видит что нужные ему продукты в наличие, накидывает рецепт, сабмитает - и получает обратно "сори, на самом деле ваши продукту уже утащили". Ведь наш ModelManager будет заботиться о синхронизации перед непосредственным сохранением в базу (когда юзер уже сделал много стэпов). Это классический кейс конкуренции за общий ресурс (в нашем случае холодильник). Единственный выход что я вижу - это временное "бронирование" продукта, т.е. при любом обновлении модели (которое могут обновить другие клиенты) нужно делать колл в базу и лочить какой-то ресурс на определённый промежуток времени. Я вот всё хочу попробовать в продакшене, но боюсь что на нашем энтэрпрайзе это рано или поздно вылезет боком (с ростом сложности модели(ей) и агрегаций)

Смысл, конечно есть, но в долгую имхо ветка Product Owner -> Product Manager в сочетании с английским уровня от C1 намного более перспективна.

Ты все верно понял :)

А разве DDD не занимает только М из MVC? Правда, в таких проектах чаще 4 слоя. Слой предметной области, слой инфраструктурной области, сервисный слой, слой приложения.

@@user-no1ig1er9s Люди по разному понимают DDD, у кого-то действительно доменный дизайн это только часть модели из MVC. У других MVC используется внутри закрытых контекстов. Что стоит понимать под МVC? MVC паттерн может быть использован в бизнес логике домена для своих внутренних целей разделения контроля за производство отображений. Третьи понимают под DDD методологию, придуманную проблемными аналитиками, чтобы они поимели ощущение причастности к разработке.

В 99% случаев - да. Готовые датамапперы не позволят сделать наоборот. Но надо понимать, что DDD это про бизнесс, а не про хранение данных. Например, в виде исключения (а точнее, если Вы взвесили все плюсы и минусы) можно сделать и так: Вы пилите легас, и у вас уже случилась одна жирная таблица, содержащая два различных BoundedContext, и разделить данные сложно, то можете попробовать запилить такое сохранение сущностей (такой UnitOfWork), чтобы разные бизнес сущности (Entity\Aggergates) сохранялись в одну табличку.

В одной. Дтошки разные

Иметь plain объект описывающий одну строку из таблички только с одним методом SAVE - да, пожалуйста, используйте. Но фаулеровский "ActiveRecord" это смесь save() и других бизнесовых методов. Это легко на старте, но через пару недель за один запрос на сервер появляется несколько вызовов save() и вот уже и перфоманс проседает и тесты влом писать, ибо не сценарий, а полотно моков и тд :)

@@Biankouski Упакуй весь бизнес-процесс над объектом в одном хранимку на сервере, получишь один save

ну концепции ддд до 1С не дорасти, т.к. есть священое писание ддд и развития не предполагает. мешает наложение ооп. то что они считают методом модели (домена) является само по себе моделью (доменом)

О да, спасибо за понимание! Я пытался убедить лекса дать доску, но сошлись что "формат не тот". А вот то, что он "не сложный" зависит от прогресса :)