НАВИГАЦИЯ: 0:00 Начало 0:50 Представление 1:55 Детство в деревне 6:29 Интеграция 8:30 Лицей БГУ 13:00 В PHP через комбайнёра 21:45 Армия 30:50 Работа после армии бэкендером 38:40 Про php и Symfony 47:10 DDD на примере холодильника 53:25 Терминология 58:45 Модели 1:26:55 Репозитории 1:35:55 Сервисы 1:39:40 Контексты и модули 1:43:20 Агрегаты 1:48:06 Луковичные архитектуры (onion architecture) 1:59:35 Что почитать 2:01:57 РАНДОМ 2:09:17 КОНКУРС 2:12:58 Послешоу
Спасибо, интеревью интересное, спикер интересный, но объяснение хромает 56:00 про пиццерию пример - есть пиццерия, у неё есть разные "отделы": кухня, продажи, склад - это домены. Когда ты реализуешь домен кухни, ты должен иметь "общий язык" с поварами, они говорят пицца - ты понимаешь что это тесто с сыром, томатной пастой и далее по списку. Пицца для продажников - это другое, для них пицца - это готовое кулинарное изделие, в коробке, готовое к транспортировке, соответственно продажи это другой домен и там у Вас свой "общий язык". DTO нужны чтобы допустим перенести пиццу из домена "кухни" в домен "продаж", скорее всего с участием домена "склада". Со склада Вам нужна коробка, с кухни само изделие, а затем в продажах Вы вешаете цену.
Всегда забавляет то, как люди поясняют сложную тему на казалось бы простом примере, но из-за простого примера(очевидно не подходящего) становиться всегда ещё только хуже
А все потому что эта сложная тема еле натягивается даже на простой пример. А на реальном сложном бизнесе придется в эти доменные сущности инжектить по 50 сервисов со всеми вытекающими проблемами с производительностью общения с базой.
@@valeravalera6201 поверьте, когда идут реальные примеры, все в разы проще, это в 100 раз проще понять когда у тебя просто микросервисы есть, а не какой-то монолит с одинаковым классами "Холодильник" которые лежат в разных модулях/неймпейсах. Любая ссылка про ДДД в гугле, намного понятнее это все поясняет, уверен гость понимает о чем говорит, но выбор "Холодильник + Монолит" объективно неудачный.
Лекс, классный и позитивный выпуск! Спасибо вашей команде! Нравятся твои видео, не напряжные и хорошо поставленные, хорошая атмосфера без всякого пафоса. Всем хорошего просмотра) Лекс, майка - огонь!)
По поводу ответов на рандомные вопросы. Как сказал Егор Малкевич (с которым есть охрененное интервью на этом канале) На вопрос, какой язык программирования учить в предстоящем году, я наконец то знаю правильный ответ - английский!
К вопросу "Зачем нужен сервис, почему бы сразу с контроллера не управлять моделью?". Точек входа для выполнения одного и того же действия может быть несколько. Это может быть HTTP запрос, крон задача или ивент на который подписано приложение. Здесь очень важно, чтобы все эти точки входа оперировали моделью одинаково. То есть они должны вызывать один и тот же сервис, часто ещё применяют термин "use case". Отсюда получается, что задача контроллера и слушателя, который подписан на ивент, это преобразовать входящие параметры в параметры сервиса и вызвать его. Так сохраняется общая логика оперирования моделью. Именно по этому, такие сервисы ещё называют операционными и они размещаются в операционном слое (Application layer).
Зачем нужен сервис в DDD: сервис нужен для того чтобы 'спаять' два и более агрегата в одну транзакцию. Например, агрегатСклад.вывезти(уголь, 3тонны) и агрегатСчетПользователя.списать(КоммунальныеКслуги, 3 тонны * 1000руб/за тонну) И вот эти две операции должны быть в транзакции. Иначе консистентность данных в базе нарушится.
Но по хорошему два агрегата обновлять два агрегата в одном сервиса эта идея уже с запашком. Так как в первую очередь она не масштабируема, сложно переносима между между типами баз данных, например на реляционной базе данных этот пример будет работать, а в MongoDB уже его придётся переписывать, так как там нет транзакций между коллекциями документов. Вопрос как же быть в таком случае. Нужно определиться с какие у нас есть возможности баз данных, вот например, в MongoDB всё операции модификации атомарны на уровне документа. В реляционках есть транзакции. Теперь проводим черту между ними. Черта проходит ровненько через агрегат. Единственное что мы можем гарантировать для того чтобы система была консистента и масштабируема в одно и тоже время, так это атомарность агрегата на уровне апликешен логики. И тогда получается сервис как бы становится антипаттерном в данном случае. То есть проще как сказано выше просто из фабрики или репозитория дёрнуть агрегатСклад.вывезти() и сохранить агрегат в базу через репозиторий: репозиторийСклад.сохранить(агрегат склад). В методе сохранить будет конкретная имплементация под базу данных в MongoDB документ атомарен, а в SQL нужно будет создать транзакцию, если потребуется модифицировать записи из нескольких таблиц. В данном кейсе мы как пока решили ровно половину задачи выше касательно склада, назовем её левой ногой). Теперь нам нужно что-то решить с правой ногой то есть со списывание денег со счета пользователя. Пока без деталей применяем тот же подход что и для склада, ровно точно также. То есть у нас появляется правая нога. Обе эти ноги по отдельности они абсолютно масштабируемы, не зависисмы ни от базы данных, ни от фрейворков, чистая бизнес логика, которую можно и в браузере на JS запустить с in memory базой и на Lambda выполнить с бесконечным масштабированием, и протестировать, геркен тесты написать. Теперь есть выбор, можно раскидать эту логику в микросервисы, наносервисы, или оставить в монолите без изменения бизнес логики. Теперь остаётся самый важный этап как прикрутить две ноги к телу. Тут есть несколько вариантов, как по мне так мне ни один не нравится. Пример напишу в следующем коменте:
Варианты связки агрегатов, есть условие система должна быть масштабируема, но при этом есть другое условие, что атомарность мы гарантируем на уровне агрегата. В этом случае нам точно не подходят транзакции SQL, так как это привязка к типу базы, а так же это сразу блокирует масштабируемость. Нам не подходят по тойже причине распределеннные транзакции, то есть 2-3 фазные комиты. Единственный вариант на текущий момент, который можно прикрутить с довольно высокой степенью сложности реализации, так это асинхронное взаимодействие, тот самый event-driven development. Реализация вроде как проста, обычно виду два варианта, первый: пуляем ивенты в момент сохранения агрегата в базу или в очередь ивентов, а с другой стороны их обрабатываем. При такой асинхронной работе обычно нужно решать подзадачу, которая звучит так: "если уголь со склада вывезли (кинули ивент), но денег на счёте пользователя не хватило для оплаты, то верните (кинули ивент) пожалуйста уголь на склад". (То что в кавычках это и есть тот самый ubiquitous language, мы уже на нем общаемся если что 😀). Можно перефразировать: "отложите на складе 3 тонны угля для пользователя и когда пройдет оплата, то вывезите уголь со склада для пользователя." Вы поняли что у нас появились пара новых слов в нашем глобальном языке для агрегата склад: "отложить" и "вернуть". Как вы выберете будет зависеть от вашего бизнеса и требований. Теперь получается задача решена, но сложность системы повышена раза в 3. За счёт асинхронных компенсирующих операций. В этом примере есть на самом деле очень низкоуровневая проблема с самим процессом кидания ивента. Что если агрегат сохранился в базу, но сообщение не отправилось в очередь так как не было связи. Ну это уже отдельная тема.
Такое ощущение что когда строил большой проект - мыслил 50/50 моделями как в DDD; Но вот на тесты не обращал внимания совсем :(; Но теперь захотелось больше!); Вы мои герои 💖💖💖
Супер! Это просто топ! Я долго не мог въехать в DDD, а этот парень так просто и интересно об этом рассказал, разложил по полочкам! Как по мне, один из самых полезных роликов на канале! Давай ещё в таком же духе!
Так в разработке ПО большая доля работы заключается в правильной комминикации с заказчиком. DDD просто упрощает жизнь разработчикам на больших длительных проектах с изменяющимися условиями. Для стартапов очень хорошо подходит.
Аааааа, Алексей, что ты делаешь?!!!! :) Последнее время каждый новый гость, это просто праздник для сердца и ушей! Столько дел в воскресенье не переделаю из за твоего выпуска :) Спасибо огромное!!!
Хорошо. Это работает с 1 доменом. Допустим, с теми-же лифтами. Что делать, если доменов много и модель лифта необходима в 5 вариациях? Если я сделаю 1 модель для 5 доменов, то она будет устрашающе огромной. Но необходимы данные для лифта всех пяти доменов. Какой может быть стратегия построения моделей/классов в таком случае? Например (наброски): 1. Доставка (комплектация запчастей, квалификация персонала, который допущен к работам); 2. Монтаж/демонтаж (конфигурация места установки, совместимая с лифтом, дополнительные работы по подготовке к лифту); 3. Установка ПО; 4. Сигнализация планового тех обслуживания, система охраны, health check; 5. Система камер видеонаблюдения за лифтом.
Я из Mobile разработки, мне было очень интересно послушать! В реальности TDD один раз за 8 лет использовали. Тогда давно не понял, а это прям тема. Спасибо за выпуск!
DDD, как я понимаю, не обязательно про ООП. Стратегическая составляющая вообще про бизнес, аналитику и т.д. а тактические паттерны ничего не мешает и в процедурном стиле реализовать (к примеру)
Related to SOLID and single responsibility. Robert Martin in book "Clean Architecture" specifying that this principle relies to single actor, doesn't tell that a class shall be responsible for single action or thing to do, but relies to reason why you have to change this class. I guess a good example refrigerator, two models for two actors, cook and mechanic.
Лекс, привет! Очень классный выпуск). Как тебе идея в следующий раз принести планшет или ноут со стилусом, чтобы гость рисовал схемки или схематично писал код для большего понимания и удержания в голове всех мелочей? И вывести все это где-нибудь на экран.
А знаете, почему канал называется АйТиБорода? Не каждый догадается, но я готов прийти на помощь всем интересующимся! Итак, во-первых, канал об информационных технологиях. А во-вторых, у ведущего есть вполне заметная борода! Всё гениальное просто! Главное быть любопытным, наблюдательным и верить в себя!
Лекс, привет! Сложно кратко описать словами, как мне нравятся твои интервью. Сколько уже посмотрел, и ни одного неинтересного собеседника встретил. Особо радует твой простой и свойский, "без понтов", подход ко всему. Лично я сейчас занят изменением своих подходов к работе, и твои видео о DDD в частности и о новых технологиях вцелом очень помогают мне понять, где мои рассуждения верны, а где нет. Особо приятно замечать тот же, что и у самого себя, блеск в глазах собеседников, когда они рассказывают о своих первых шагах в IT. Удивительно, мой путь и путь твоих гостей во многом похожи. В общем, так держать!
2:03:35 S. в single responsible это не про то что один класс\сущность - одна задача. Класс отвечает принципу единой ответственности если есть только одна причина для его изменений. Именно поэтому кухонный холодильник не может иметь метод взятьИнгридиенты и отремонтировать. Потому что тогда класс придется менять если меняется логика получения ингредиентов или логика ремонта.
"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 реквесты. Такого, конечно, не будет, но смысл в том что бы вы могли написать свервис не думая о фреймворке и базе,
Посмотрел, чтобы подтвердить свое мнение. DDD - отличный подход, что-бы быть ближе к бизнесу. Формировать архитектуру и сущности проекта в соответствие с требованиями/задачами бизнеса. Работаю по DDD последние пару лет. Рекомендую попробовать, тем кто еще не использует
Прекрасное интервью! Мне очень понравилось, как Борис рассказал про DDD. Но не могу согласиться с тем, что 15 лет в разработке - это очень много... Всё, что мы используем в разработке сейчас (2021), придумано в 1960х: процедурное, функциональное, ООП, юнит-тестирование и ТДД - придумано и опробовано тогда.
@@bellmoon2754 "Автор" ТДД Кент Бек сам писал, что он переоткрыл эту идею, а не изобрёл её заново. И он ссылается на идею с перфокартами, которая описывает процесс ТДД.
@@ivan_lebedev DDD - это чистое объектно-ориентированное программирование. В нём новым оказывается позабытое старое, когда в 60х программисты знали предметную область и писали программы от неё отталкиваясь. В современном мире программисты абстрактные - они могут запрограммировать всё, но мало в каких предметных областях разбираются. И DDD напоминает, что вообще-то мы моделируем реальный мир и его конкретную часть, используя ООП.
красиво рассказывает, вот только нифига этот DDD по факту не работает когда в бизнес-процесс добавляется какая-либо логика которая затрагивает большое количество данных или включает более сложную логику чем обычный круд (добавить/достать). Когда везде требуется оптимизация данных, подготовка данных, постпроцессинг, атомарность.
а что работает, когда "в бизнес-процесс добавляется какая-либо логика которая затрагивает большое количество данных или включает более сложную логику чем обычный круд"?
@@kivinus1575 в конце интервью сам Борис говорит что это не про перфоманс, поэтому если не нужен перфоманс, если работа приложения асинхронная, то можно и DDD. Иначе ни о каком DDD речи нет. Конечно стоит абстрагивароться от окружения, но если перфоманс в приоритете, то абстрагироваться от хранилища и его особенностей не получится, от кэшей абстрагивароться не получится. Если попытаться скрестить DDD и производительность, то можно в какой то степени прийти к CQRS.
@@sluchznak > но если перфоманс в приоритете Это ведь был блитц) и я пытался донести мысль только про "если перфоманс - это приоритет №1". Условно драйверы, да микроконтроллеры. Что-то, где вы даже зря выбрали для задачи язык с виртуальной машиной (Java, C#, интепритаторы и тд) :D Ну, либо, это огромное кол-во моделей (десятки тысяч) на приложение прокси (типичное серверное приложени проксирующее запрос на генерацию репорта к СУБД). Если этот прокси не делает никакой собственной логики, то создавать сложные агрегаты, только что-бы их сразу разобрать - действительно глупо В остальном "не стоит делать преждевременные оптимизации". 90% enterpise проектов, которые тупят - тупят потому-что код макароны, и на одном запросе к серверу читают и пишут в БД одни и те же строчки по N раз. Или N+1. Или сохраняют то что не поменялось. Казалось бы, не много логики, а уже по времени не вывозит. А DDD дает UoW который решает эти проблемы, и код читабельный, и тесты. До какой-то степени, UoW (на самом деле вы удивитесь - большой степени) - не является проблемой для веб сервера. А из-за того что код читабельнее, всегда можно код в боттлнеках зарефачить (и только те места, которые этого действительно требуют) Кроме UoW, DDD не диктует никаких потенциально (!) медленных практик: просит разделять простыни логики (ифов и циклов) на чистые "домен", инфраструктурные, да сервисы - которые все это склеивают. Затраты только на дополнительные вызовы функций. А что делать, если вызовы функций для вас стали ботлнеком, - я предложил в начале комментария :)
Ого! Огромное спасибо!!! Это архиполезный выпуск в разрезе ВЗАИМО понимания конечного заказчика и конечного исполнителя, которые, как зачастую бывает, живут в разных мирах! Класс!!!
Верно подмечено что DDD это не "правила", а "пожелания". Помогал знакомому переписывать MVP`шку на новый рельсы - и подсунул ему легкий уровень DDD... Ему было крайне тяжело, всегда хотелось писать сразу в контроллере, но я его тормозил и заставлял все расписывать по доменам, агрегаторам, моделям и т.д. Времени было заложено на "реврайт" 4 месяца, сроки из-за сложности первичного входа растянулись до 5 месяцев. И через неделю после старта новой версии, заказчик прибежал с новой идеей - сколько было счастья в его голосе, когда он рассказывал что в MVP ему пришлось бы треть кода переписывать, а тут сделал новый домен, сформировал агрегатор и настроил роуты - готово. При этом 99.99[9]% гарантии что ничего ранее написанного не сломалось. ---- Полностью согласен с Борисом - главное начать, будет тяжело, будет "ломать" писать каждую новую "фишку" в пяти-семи местах, вместо одного куска кода в контроллере - зато потом начнешь пожимать плоды своих трудов. === Теперь дам ему ссылочку на данное видео - а то ведь даже не знает что это было DDD (хоть и маленькое, но все же) 😀
Александр, а вы могли бы привести пример домена? Например, как ваш колета сделал новый домен, сформировал агрегат? Может от себя что-нибудь посоветуете, с чего начать для изучения этой темы?
DDD очень сладко звучит, но я для себя так до конца и не понял как происходит синхронизация работы с базой? (в особенности когда много серверов, юзеров и т.д., ведь модель - это по сути InMemory объект, который зачастую имеет очень много зависимостей, даже на очень простых бизнес моделях) Можно конечно запилить exclusive lock, но в таком случае с перфомансом можно прощаться на веки (даже для небольших моделей, про средние и выше - промолчим). Да и не очень понятно как это всё ложиться на REST API (где мы фокусируемся не на бизнесе модели, а на ресурсах, читай данных). Очень интересен DDD, очень ждал ответа на эти вопросы, но не дождался (как и во многих других выступлениях про DDD)
> который зачастую имеет очень много зависимостей, даже на очень простых бизнес моделях) скорее всего у вас нарушается разделение 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 будет заботиться о синхронизации перед непосредственным сохранением в базу (когда юзер уже сделал много стэпов). Это классический кейс конкуренции за общий ресурс (в нашем случае холодильник). Единственный выход что я вижу - это временное "бронирование" продукта, т.е. при любом обновлении модели (которое могут обновить другие клиенты) нужно делать колл в базу и лочить какой-то ресурс на определённый промежуток времени. Я вот всё хочу попробовать в продакшене, но боюсь что на нашем энтэрпрайзе это рано или поздно вылезет боком (с ростом сложности модели(ей) и агрегаций)
В теории звучит очень интересно, но либо я прослушал либо не могу понять, а на каком уровне проводить сложную валидацию? Например, повар хочет взять из холодильника сыр для пиццы, а мы должны проверить доступен ли сейчас холодос для взятия сыра (не занят ли кем то), есть ли в нем сыр, есть ли права у повара на использования этого сыра и может ли он запустить механизмы и открыть дверь для выдачи сыра (например у нас электронный замок которым управляет система и холодос в онлайне) Итого, У нас валидация разделяется на типы: бизнес валидация, валидация безопасности, валидация уровня инфраструктуры (в сети ли холодос и может ли открыть замок) Вопрос: Где проводить валидацию? 1. На уровне контроллера 2. На уровне сервиса 3. На уровне бизнес модели (если да, то как не смешать слои?) 4. Валидировать на каждом уровне свою ответственность (если да, то как не размазать сам контекст всего действия?)
разная валидация в разном месте. Зависит от того, какую предметную область мы описываем. Агрегат и входящие в него сущности и объекты-значения отвечают за валидацию бизнес-инвариантов. Domain services могут осуществлять валидацию, которая распространяются сразу на несколько агрегатов, но нужно быть аккуратным с транзакционностью. Application services обычно как раз отвечают за аутентификацию, авторизацию и т.п. Например, разные права можно описать разными типами: Шеф-повар и просто Повар. У них будет разный интерфейс, однозначно определяющий набор доступных операций. Плюс нужно будет подумать крепко, является ли Шеф просто Поваром, то есть нужно ли здесь наследование. Это как раз хороший пример, когда имеет смысл пообщаться с бизнесом и спросить: А может ли вообще шеф выполнять работу обычного повара? Если же у нас какой-то мощный DACL и attribute-based authorization, то проверку желательно вынести в отдельную службу и эти службы уже использовал в операциях бизнес-моделей. Но связности и нарушения инкапсуляции здесь уже не миновать. Вообще, инкапсуляция - штука очень контекстная. Так слой доступа к данным должен уметь заглядывать в private поля и свойства, чтоб положить данные в хранилище.
На все 100% согласен с утверждением "У меня было программирование до DDD и после". Я всем знакомым говорю так: "Я как разработчик до DDD и после это два разных разработчика". Эти принципы кардинально поменяли мой взгляд на программирование.
*_Надеюсь доживу до того дня, когда увижу в названии нового видоса "Язык ассемблера....."._* *_Ну и по классике вопрос: -Айтиборода, где ассемблер?_* 😂
Полностью согласен с тем что тут обсуждаете по DDD) Инварианты и программирование по контракту пришли от Бертрана Майера Bounded Coxtext DDD = SRP Дяди Боба Рано или поздно начинаешь замечать где и какие принципы заложены)
1:23:00 может дальше будет объясняться. По идее сервис нужен для того, чтобы не привязываться к инфраструктуре. То есть может быть веб контроллер (с гетом), консоль контроллер (с параметрами) и дальше уже на что фантазии хватит
Я не могу отделаться от мысли, что всё это сводится к идеям из Grokking Simplicity, точнее к трём вещам: 1. Данные (Data): факты, которые могут использоваться как угодно. 2. Функции-расчёты (Calculations): когда на любой вход, у нас одинаковый выход. В видео это называли без side-effect'ов. 3. Функции-Действия (Actions): что угодно зависящее от того, когда было вызвано или сколько раз. Любое действие "заражает" всё что выше. В примерах это было ActiveRecord, вызов функции now () и т.п.
Борис немного напутал с unit of work (UoW), от того он и сказал что "не знаю почему его так назвали" UoW отвечает за то чтобы изменения сохранялись атомарно, от того он так и называется а то о чём говорил Борис (холодильники с одним id будут одним и тем-же холодильником) -- это Identity map
Мне 36 лет я инженер-конструктор на 1:22:00 я подумал "да ну нахрен, я пошел" но все же досмотрел! Правда у меня есть образование программиста, но в 2007-2011 году у меня с этим не задалось! Спасибо за видосы
Наверное моё ИМХО, но про ДДД без вайтборда рассказывать нельзя))) Мало внимания было уделено immutable. И объяснение UoW мне, как шарписту, совсем не понравилось. В целом, гут, чел без заготовленного текста рассказал сложную тему. Но, ведь ДДД не сложный, если рассказывать, не прыгая с место на место ;)
очень плохой выпуск. думал намного лучше будет. "у нас всё в модели, но правда есть ещё просто сущность, а есть ещё сервис..." и на примере пицерии, ага... реально вопросы подхода "анемичной против жырной модели" актуален для автоматизации/моделирования чего-то сложного типа большой фирмы.
Коллеги, выскажу своё скромное мнение, DDD это круто, когда умеешь его готовить, но готовить как Борис мне не нравится. У этого парня отсутствует понимание связности процессов. Он для приготовления пиццы делает одну модель про холодильник, а для обслуживания холодильника другую. Нельзя управление над сущностью разносить. Он теряет связность и прозрачность управления (всё в одном месте). Как готовить пиццу, если холодильник на обслуживании? Ну и т.д. Также не услышал в интервью зачем Борис использует репозитории, хотя Лекс спрашивал. В этом тоже собака порылась, ну не понимает корней или ловко уклоняется Борис от ответа.
Не надо готовить "как Борис". Это был поток мыслей экспромтом :) Больше реклама DDD нежели учебник. Проследуйте, пожалуйста, по ссылкам под видео (или где они там), если хотите учебного материала > Он теряет связность и прозрачность управления (всё в одном месте). Абсолютно с Вами согласен. Разбивать "ради разбивания" не стоит. Я пытался (видимо, не удачно получилось) показать как работают BoundedContext. Если говорить про микросервисы, то один BoundedContext - это микросервис. В монолитах это модуль (или пакет) > Как готовить пиццу, если холодильник на обслуживании? В моем примере этого не было. В моем примере (там... кхм.. я заказчик :D внезапно ) кухня и ремонт никак не связаны, кроме факта очистки холодоса. Например, "готовят из первого доступного холодильника" Вообще, если такой вопрос встает (как готовить если на обслуживании) то нужно спрашивать у заказчика. Может действительно оказаться, что это крайне связанно, и никаких раздельных контекстов тут нет. В моей практике такое встречалось - что когда код "не ложился", подсвечивали это продукт овнерам, и овнеры осознавали, что у них кривые требования, и они их меняли Спасибо за фидбек
Борода, спасибо за видео. Теперь смогу с легкостью Эванса дочитать ) Не хватало общего понимания без кучи деталей, из которых и состоит книга. level up )
На мой взгляд, можно читать только bounded context. Сам Эванс через цать лет после первой книги сказал, что это ключевая идея. И если писать вторую редакцию, то именно это будет центральной частью.
В зависимости от реализации, конечно, но MVC может провоцировать technologically partitioned структуру проекта, в свою очередь, DDD провоцирует следование в сторону domain partitioned структуризации ваших модулей.
А разве DDD не занимает только М из MVC? Правда, в таких проектах чаще 4 слоя. Слой предметной области, слой инфраструктурной области, сервисный слой, слой приложения.
@@КлинокСтальной Люди по разному понимают DDD, у кого-то действительно доменный дизайн это только часть модели из MVC. У других MVC используется внутри закрытых контекстов. Что стоит понимать под МVC? MVC паттерн может быть использован в бизнес логике домена для своих внутренних целей разделения контроля за производство отображений. Третьи понимают под DDD методологию, придуманную проблемными аналитиками, чтобы они поимели ощущение причастности к разработке.
Мне показалось, что в видео DDD было маловато (читал только сине-зелёную книжку Вона Вернона). Немножко прошлись по ограниченным контекстам и единому языку, немножко по агрегатам (но объяснение крайне расплывчатое на мой взгляд). Что касается богатых и бедных моделей, то богатые модели предпочтительнее и крайне рекомендуется, если использовать DDD, но их отсутствие вполне сочетается с подходом. Большая часть видео скорее про архитектуру лука и изоляцию логики. Часть про репозитории интересная, но напрямую не касается DDD и onion architecture. У меня пока сложилось впечатление, что DDD - это больше про проектирование (создание правильной концептуальной модели с событиями, агрегатами) и привлечение бизнес-экспертов в твоё проектирование. Поэтому был удивлён, что заказчику не нужно продавать DDD.
Привет! У тебя очень крутые интервью! Очень прошу, может найдешь на интервью человека, который занимается VR? Мне кажется очень интересное направление, многим зайдёт
поддерживаю идею приходить в универы послушать лекции! вот это реально было бы круть! хотя бы пусть бы онлайн трансляции сделали, можно платно. огонь тема!
Скажите, Борис, а где можно ознакомиться с примерами вашего кода, в котором применен DDD, не обязательно реальный, вполне сгодится чтото вроде пиццерии с холодильниками.
НАВИГАЦИЯ:
0:00 Начало
0:50 Представление
1:55 Детство в деревне
6:29 Интеграция
8:30 Лицей БГУ
13:00 В PHP через комбайнёра
21:45 Армия
30:50 Работа после армии бэкендером
38:40 Про php и Symfony
47:10 DDD на примере холодильника
53:25 Терминология
58:45 Модели
1:26:55 Репозитории
1:35:55 Сервисы
1:39:40 Контексты и модули
1:43:20 Агрегаты
1:48:06 Луковичные архитектуры (onion architecture)
1:59:35 Что почитать
2:01:57 РАНДОМ
2:09:17 КОНКУРС
2:12:58 Послешоу
Ну какое нафиг 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
Пригожин отрастил бороду и тоже начал вникать
Чуть чуть похож реально
Было бы круто, если бы такие вещи обсуждались с доской, на которой можно порисовать свои мысли)))
Спасибо, интеревью интересное, спикер интересный, но объяснение хромает
56:00 про пиццерию пример - есть пиццерия, у неё есть разные "отделы": кухня, продажи, склад - это домены.
Когда ты реализуешь домен кухни, ты должен иметь "общий язык" с поварами, они говорят пицца - ты понимаешь что это тесто с сыром, томатной пастой и далее по списку.
Пицца для продажников - это другое, для них пицца - это готовое кулинарное изделие, в коробке, готовое к транспортировке, соответственно продажи это другой домен и там у Вас свой "общий язык".
DTO нужны чтобы допустим перенести пиццу из домена "кухни" в домен "продаж", скорее всего с участием домена "склада". Со склада Вам нужна коробка, с кухни само изделие, а затем в продажах Вы вешаете цену.
вот вы объяснили лучше, чем спикер за все видео
Вот. Сразу чувствуется структурное мышление
Домен - это вся пиццерия. Отделы - это bounded context.
@@timur43378 bounded context это бухгалтерия, рецепты, табель, меню. Для начала в терминах разберись
Так я ДДД. Каждый день делаю запросы в холодильник!
У него чёрный пояс по гастрономическим метафорам
Судя по пузику Лекса, он тоже не отстает
@@smookkee1 самое лучшее пузико на этой планете!
Ты Service)
Люблю программистов из деревни - умеют простыми и понятными словами объяснять сложные вещи
Это индикатор понимания, причина почему полезно не только учится но и учить.
Всегда забавляет то, как люди поясняют сложную тему на казалось бы простом примере, но из-за простого примера(очевидно не подходящего) становиться всегда ещё только хуже
А все потому что эта сложная тема еле натягивается даже на простой пример. А на реальном сложном бизнесе придется в эти доменные сущности инжектить по 50 сервисов со всеми вытекающими проблемами с производительностью общения с базой.
@@valeravalera6201 поверьте, когда идут реальные примеры, все в разы проще, это в 100 раз проще понять когда у тебя просто микросервисы есть, а не какой-то монолит с одинаковым классами "Холодильник" которые лежат в разных модулях/неймпейсах.
Любая ссылка про ДДД в гугле, намного понятнее это все поясняет, уверен гость понимает о чем говорит, но выбор "Холодильник + Монолит" объективно неудачный.
Лекс, классный и позитивный выпуск! Спасибо вашей команде!
Нравятся твои видео, не напряжные и хорошо поставленные, хорошая атмосфера без всякого пафоса.
Всем хорошего просмотра)
Лекс, майка - огонь!)
спасибо!
Открываешь холодильник, а оттуда exception вылетает. Люблю DDD!
Call to a member function getKolbasa() on null
@@vesh95 В голос 🤣🤣🤣
в тему выпуск! Книгу можно еще почитать - Вернон В. - Реализация методов предметно-ориентированного проектирования
Ее лучше на английском читать, перевод там ужасен
Davay Davay Deploy
По поводу ответов на рандомные вопросы.
Как сказал Егор Малкевич (с которым есть охрененное интервью на этом канале)
На вопрос, какой язык программирования учить в предстоящем году, я наконец то знаю правильный ответ - английский!
Наверное самый позитивный гость из всех, кто были на этом канале. Ждём ещё Макса True
Ещё был про с# и релокейт в Чехию позитивный гость)
Лекс и Борис, ну это пушка, посмотрел на одном дыхании))
Борис, не задумывался над собственным каналом?
К вопросу "Зачем нужен сервис, почему бы сразу с контроллера не управлять моделью?". Точек входа для выполнения одного и того же действия может быть несколько. Это может быть HTTP запрос, крон задача или ивент на который подписано приложение. Здесь очень важно, чтобы все эти точки входа оперировали моделью одинаково. То есть они должны вызывать один и тот же сервис, часто ещё применяют термин "use case". Отсюда получается, что задача контроллера и слушателя, который подписан на ивент, это преобразовать входящие параметры в параметры сервиса и вызвать его. Так сохраняется общая логика оперирования моделью. Именно по этому, такие сервисы ещё называют операционными и они размещаются в операционном слое (Application layer).
Досмотрел до этой точки th-cam.com/video/rkQ3-T82pkU/w-d-xo.html , главную ответственность сервиса упомянули.
Зачем нужен сервис в DDD: сервис нужен для того чтобы 'спаять' два и более агрегата в одну транзакцию. Например, агрегатСклад.вывезти(уголь, 3тонны) и агрегатСчетПользователя.списать(КоммунальныеКслуги, 3 тонны * 1000руб/за тонну)
И вот эти две операции должны быть в транзакции. Иначе консистентность данных в базе нарушится.
Но по хорошему два агрегата обновлять два агрегата в одном сервиса эта идея уже с запашком. Так как в первую очередь она не масштабируема, сложно переносима между между типами баз данных, например на реляционной базе данных этот пример будет работать, а в MongoDB уже его придётся переписывать, так как там нет транзакций между коллекциями документов. Вопрос как же быть в таком случае. Нужно определиться с какие у нас есть возможности баз данных, вот например, в MongoDB всё операции модификации атомарны на уровне документа. В реляционках есть транзакции. Теперь проводим черту между ними. Черта проходит ровненько через агрегат. Единственное что мы можем гарантировать для того чтобы система была консистента и масштабируема в одно и тоже время, так это атомарность агрегата на уровне апликешен логики. И тогда получается сервис как бы становится антипаттерном в данном случае. То есть проще как сказано выше просто из фабрики или репозитория дёрнуть агрегатСклад.вывезти() и сохранить агрегат в базу через репозиторий: репозиторийСклад.сохранить(агрегат склад). В методе сохранить будет конкретная имплементация под базу данных в MongoDB документ атомарен, а в SQL нужно будет создать транзакцию, если потребуется модифицировать записи из нескольких таблиц.
В данном кейсе мы как пока решили ровно половину задачи выше касательно склада, назовем её левой ногой). Теперь нам нужно что-то решить с правой ногой то есть со списывание денег со счета пользователя. Пока без деталей применяем тот же подход что и для склада, ровно точно также. То есть у нас появляется правая нога. Обе эти ноги по отдельности они абсолютно масштабируемы, не зависисмы ни от базы данных, ни от фрейворков, чистая бизнес логика, которую можно и в браузере на JS запустить с in memory базой и на Lambda выполнить с бесконечным масштабированием, и протестировать, геркен тесты написать. Теперь есть выбор, можно раскидать эту логику в микросервисы, наносервисы, или оставить в монолите без изменения бизнес логики.
Теперь остаётся самый важный этап как прикрутить две ноги к телу. Тут есть несколько вариантов, как по мне так мне ни один не нравится. Пример напишу в следующем коменте:
Варианты связки агрегатов, есть условие система должна быть масштабируема, но при этом есть другое условие, что атомарность мы гарантируем на уровне агрегата. В этом случае нам точно не подходят транзакции SQL, так как это привязка к типу базы, а так же это сразу блокирует масштабируемость. Нам не подходят по тойже причине распределеннные транзакции, то есть 2-3 фазные комиты.
Единственный вариант на текущий момент, который можно прикрутить с довольно высокой степенью сложности реализации, так это асинхронное взаимодействие, тот самый event-driven development. Реализация вроде как проста, обычно виду два варианта, первый: пуляем ивенты в момент сохранения агрегата в базу или в очередь ивентов, а с другой стороны их обрабатываем.
При такой асинхронной работе обычно нужно решать подзадачу, которая звучит так: "если уголь со склада вывезли (кинули ивент), но денег на счёте пользователя не хватило для оплаты, то верните (кинули ивент) пожалуйста уголь на склад". (То что в кавычках это и есть тот самый ubiquitous language, мы уже на нем общаемся если что 😀). Можно перефразировать: "отложите на складе 3 тонны угля для пользователя и когда пройдет оплата, то вывезите уголь со склада для пользователя." Вы поняли что у нас появились пара новых слов в нашем глобальном языке для агрегата склад: "отложить" и "вернуть". Как вы выберете будет зависеть от вашего бизнеса и требований.
Теперь получается задача решена, но сложность системы повышена раза в 3. За счёт асинхронных компенсирующих операций.
В этом примере есть на самом деле очень низкоуровневая проблема с самим процессом кидания ивента. Что если агрегат сохранился в базу, но сообщение не отправилось в очередь так как не было связи. Ну это уже отдельная тема.
О, Поперечный стал хорошо питаться.
Такое ощущение что когда строил большой проект - мыслил 50/50 моделями как в DDD; Но вот на тесты не обращал внимания совсем :(; Но теперь захотелось больше!); Вы мои герои 💖💖💖
Супер! Это просто топ! Я долго не мог въехать в DDD, а этот парень так просто и интересно об этом рассказал, разложил по полочкам!
Как по мне, один из самых полезных роликов на канале! Давай ещё в таком же духе!
1:08:55. Gherkin, это язык. А cucumber это фреймворк который использует этот язык
Рад что в РБ есть бурления на тему DDD, я тоже из РБ и тоже интересуюсь этой темой, было бы неплохо замутить какое нить комьюнити )
Интересно! Здесь суть концепции даже не в ПО, а в организации работы с заказчиком и бизнесом...
Так в разработке ПО большая доля работы заключается в правильной комминикации с заказчиком. DDD просто упрощает жизнь разработчикам на больших длительных проектах с изменяющимися условиями. Для стартапов очень хорошо подходит.
НУ наконец то! Что-то годное в плане архитектур! А то надоели эти все ваши ООП и т.д
Аааааа, Алексей, что ты делаешь?!!!! :)
Последнее время каждый новый гость, это просто праздник для сердца и ушей!
Столько дел в воскресенье не переделаю из за твоего выпуска :)
Спасибо огромное!!!
Хорошо. Это работает с 1 доменом. Допустим, с теми-же лифтами. Что делать, если доменов много и модель лифта необходима в 5 вариациях?
Если я сделаю 1 модель для 5 доменов, то она будет устрашающе огромной. Но необходимы данные для лифта всех пяти доменов. Какой может быть стратегия построения моделей/классов в таком случае?
Например (наброски):
1. Доставка (комплектация запчастей, квалификация персонала, который допущен к работам);
2. Монтаж/демонтаж (конфигурация места установки, совместимая с лифтом, дополнительные работы по подготовке к лифту);
3. Установка ПО;
4. Сигнализация планового тех обслуживания, система охраны, health check;
5. Система камер видеонаблюдения за лифтом.
чувак реально любит пиццу
Какой ламповый и трушный гость, прям вспомнил молодость )
Я из Mobile разработки, мне было очень интересно послушать! В реальности TDD один раз за 8 лет использовали. Тогда давно не понял, а это прям тема. Спасибо за выпуск!
Офигенный гость!! Очень приятно слушать
Ооо, это залет. Scott Wlaschin - Domain Modeling Made Functional - есть DDD в мире функциональщины.
DDD, как я понимаю, не обязательно про ООП. Стратегическая составляющая вообще про бизнес, аналитику и т.д. а тактические паттерны ничего не мешает и в процедурном стиле реализовать (к примеру)
Related to SOLID and single responsibility. Robert Martin in book "Clean Architecture" specifying that this principle relies to single actor, doesn't tell that a class shall be responsible for single action or thing to do, but relies to reason why you have to change this class. I guess a good example refrigerator, two models for two actors, cook and mechanic.
Лекс, привет! Очень классный выпуск). Как тебе идея в следующий раз принести планшет или ноут со стилусом, чтобы гость рисовал схемки или схематично писал код для большего понимания и удержания в голове всех мелочей? И вывести все это где-нибудь на экран.
Ку! Идея гуд, думали доску поставить. Но! Монтаж тогда будет совсем не очень, плюс ребята, которые в аудио слушают очень расстроится, а таких много.
Так что для старта пойдет, а дальше уже можно искать целенаправленно курсы😊
Несколько месяцев назад начал погружаться в DDD. Как же знакомы все эти чувства когда впервые написал модель с поведением!
Говорим Беларусь, подразумеваем холодильники, говорим холодильники, подразумеваем Беларусь. Никак не могу избавиться от этой ассоциации.
А знаете, почему канал называется АйТиБорода? Не каждый догадается, но я готов прийти на помощь всем интересующимся! Итак, во-первых, канал об информационных технологиях. А во-вторых, у ведущего есть вполне заметная борода! Всё гениальное просто! Главное быть любопытным, наблюдательным и верить в себя!
пора бы переименовывать канал в АйТиПузико
Лекс, привет! Сложно кратко описать словами, как мне нравятся твои интервью. Сколько уже посмотрел, и ни одного неинтересного собеседника встретил. Особо радует твой простой и свойский, "без понтов", подход ко всему.
Лично я сейчас занят изменением своих подходов к работе, и твои видео о DDD в частности и о новых технологиях вцелом очень помогают мне понять, где мои рассуждения верны, а где нет. Особо приятно замечать тот же, что и у самого себя, блеск в глазах собеседников, когда они рассказывают о своих первых шагах в IT. Удивительно, мой путь и путь твоих гостей во многом похожи.
В общем, так держать!
Спасибо и удачи!))
2:12:58 я знал что будет полезным до самого конца досмотреть :)
Похоже на воплощение Закона Конвея: "Организации проектируют системы, которые копируют структуру коммуникаций в этой организации."
Лучше видео по ддд что я видел в жизни. Респектище гостю и автору
2:03:35 S. в single responsible это не про то что один класс\сущность - одна задача. Класс отвечает принципу единой ответственности если есть только одна причина для его изменений.
Именно поэтому кухонный холодильник не может иметь метод взятьИнгридиенты и отремонтировать. Потому что тогда класс придется менять если меняется логика получения ингредиентов или логика ремонта.
"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 реквесты. Такого, конечно, не будет, но смысл в том что бы вы могли написать свервис не думая о фреймворке и базе,
Это вышка! Спасибо за выпуск, я как раз изучаю DDD. Борис очень помог понять простыми словами
Посмотрел, чтобы подтвердить свое мнение. DDD - отличный подход, что-бы быть ближе к бизнесу. Формировать архитектуру и сущности проекта в соответствие с требованиями/задачами бизнеса. Работаю по DDD последние пару лет. Рекомендую попробовать, тем кто еще не использует
Прекрасное интервью! Мне очень понравилось, как Борис рассказал про DDD.
Но не могу согласиться с тем, что 15 лет в разработке - это очень много... Всё, что мы используем в разработке сейчас (2021), придумано в 1960х: процедурное, функциональное, ООП, юнит-тестирование и ТДД - придумано и опробовано тогда.
Полностью согласен
Не надо все грести под одну гребёнку, ТДД гораздо позже появился
в 2003 DDD примерно появился и TDD примерно тогда же.
@@bellmoon2754 "Автор" ТДД Кент Бек сам писал, что он переоткрыл эту идею, а не изобрёл её заново. И он ссылается на идею с перфокартами, которая описывает процесс ТДД.
@@ivan_lebedev DDD - это чистое объектно-ориентированное программирование. В нём новым оказывается позабытое старое, когда в 60х программисты знали предметную область и писали программы от неё отталкиваясь. В современном мире программисты абстрактные - они могут запрограммировать всё, но мало в каких предметных областях разбираются. И DDD напоминает, что вообще-то мы моделируем реальный мир и его конкретную часть, используя ООП.
Классный и такой позитивный гость! Интересно про пиццу рассказывает.
И какого же размера модели в DDD, в сколько хоть нибудь сложном проекте? Rich Domain Model очень сложно поддерживать, имхо.
красиво рассказывает, вот только нифига этот DDD по факту не работает когда в бизнес-процесс добавляется какая-либо логика которая затрагивает большое количество данных или включает более сложную логику чем обычный круд (добавить/достать). Когда везде требуется оптимизация данных, подготовка данных, постпроцессинг, атомарность.
а что работает, когда "в бизнес-процесс добавляется какая-либо логика которая затрагивает большое количество данных или включает более сложную логику чем обычный круд"?
@@kivinus1575 в конце интервью сам Борис говорит что это не про перфоманс, поэтому если не нужен перфоманс, если работа приложения асинхронная, то можно и DDD. Иначе ни о каком DDD речи нет. Конечно стоит абстрагивароться от окружения, но если перфоманс в приоритете, то абстрагироваться от хранилища и его особенностей не получится, от кэшей абстрагивароться не получится. Если попытаться скрестить DDD и производительность, то можно в какой то степени прийти к CQRS.
Э, а я думал, ДДД это про ситуацию, когда код сложнее чем просто круд.
К ДДД ещё можно событийную архитектуру прикрутить и отдельную модель чтения.
@@sluchznak
> но если перфоманс в приоритете
Это ведь был блитц) и я пытался донести мысль только про "если перфоманс - это приоритет №1". Условно драйверы, да микроконтроллеры. Что-то, где вы даже зря выбрали для задачи язык с виртуальной машиной (Java, C#, интепритаторы и тд) :D
Ну, либо, это огромное кол-во моделей (десятки тысяч) на приложение прокси (типичное серверное приложени проксирующее запрос на генерацию репорта к СУБД). Если этот прокси не делает никакой собственной логики, то создавать сложные агрегаты, только что-бы их сразу разобрать - действительно глупо
В остальном "не стоит делать преждевременные оптимизации".
90% enterpise проектов, которые тупят - тупят потому-что код макароны, и на одном запросе к серверу читают и пишут в БД одни и те же строчки по N раз. Или N+1. Или сохраняют то что не поменялось. Казалось бы, не много логики, а уже по времени не вывозит.
А DDD дает UoW который решает эти проблемы, и код читабельный, и тесты.
До какой-то степени, UoW (на самом деле вы удивитесь - большой степени) - не является проблемой для веб сервера. А из-за того что код читабельнее, всегда можно код в боттлнеках зарефачить (и только те места, которые этого действительно требуют)
Кроме UoW, DDD не диктует никаких потенциально (!) медленных практик: просит разделять простыни логики (ифов и циклов) на чистые "домен", инфраструктурные, да сервисы - которые все это склеивают. Затраты только на дополнительные вызовы функций.
А что делать, если вызовы функций для вас стали ботлнеком, - я предложил в начале комментария :)
Борис топит за чистый код, но не соблюдает принцип DRY для часов
Ого! Огромное спасибо!!! Это архиполезный выпуск в разрезе ВЗАИМО понимания конечного заказчика и конечного исполнителя, которые, как зачастую бывает, живут в разных мирах! Класс!!!
Верно подмечено что DDD это не "правила", а "пожелания".
Помогал знакомому переписывать MVP`шку на новый рельсы - и подсунул ему легкий уровень DDD...
Ему было крайне тяжело, всегда хотелось писать сразу в контроллере, но я его тормозил и заставлял все расписывать по доменам, агрегаторам, моделям и т.д.
Времени было заложено на "реврайт" 4 месяца, сроки из-за сложности первичного входа растянулись до 5 месяцев.
И через неделю после старта новой версии, заказчик прибежал с новой идеей - сколько было счастья в его голосе, когда он рассказывал что в MVP ему пришлось бы треть кода переписывать, а тут сделал новый домен, сформировал агрегатор и настроил роуты - готово. При этом 99.99[9]% гарантии что ничего ранее написанного не сломалось.
----
Полностью согласен с Борисом - главное начать, будет тяжело, будет "ломать" писать каждую новую "фишку" в пяти-семи местах, вместо одного куска кода в контроллере - зато потом начнешь пожимать плоды своих трудов.
===
Теперь дам ему ссылочку на данное видео - а то ведь даже не знает что это было DDD (хоть и маленькое, но все же) 😀
Александр, а вы могли бы привести пример домена? Например, как ваш колета сделал новый домен, сформировал агрегат?
Может от себя что-нибудь посоветуете, с чего начать для изучения этой темы?
Обычно под моделью в ддд понимают не класс бизнес объекта, а модель предметной области (та самая имплементация домена).
Крайне рекомендую книгу Вон Вернона
Борька красава!!! Привет из Минска!)
DDD очень сладко звучит, но я для себя так до конца и не понял как происходит синхронизация работы с базой? (в особенности когда много серверов, юзеров и т.д., ведь модель - это по сути InMemory объект, который зачастую имеет очень много зависимостей, даже на очень простых бизнес моделях)
Можно конечно запилить exclusive lock, но в таком случае с перфомансом можно прощаться на веки (даже для небольших моделей, про средние и выше - промолчим).
Да и не очень понятно как это всё ложиться на REST API (где мы фокусируемся не на бизнесе модели, а на ресурсах, читай данных).
Очень интересен DDD, очень ждал ответа на эти вопросы, но не дождался (как и во многих других выступлениях про DDD)
> который зачастую имеет очень много зависимостей, даже на очень простых бизнес моделях)
скорее всего у вас нарушается разделение 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 будет заботиться о синхронизации перед непосредственным сохранением в базу (когда юзер уже сделал много стэпов). Это классический кейс конкуренции за общий ресурс (в нашем случае холодильник). Единственный выход что я вижу - это временное "бронирование" продукта, т.е. при любом обновлении модели (которое могут обновить другие клиенты) нужно делать колл в базу и лочить какой-то ресурс на определённый промежуток времени.
Я вот всё хочу попробовать в продакшене, но боюсь что на нашем энтэрпрайзе это рано или поздно вылезет боком (с ростом сложности модели(ей) и агрегаций)
В теории звучит очень интересно, но либо я прослушал либо не могу понять, а на каком уровне проводить сложную валидацию?
Например, повар хочет взять из холодильника сыр для пиццы, а мы должны проверить доступен ли сейчас холодос для взятия сыра (не занят ли кем то), есть ли в нем сыр, есть ли права у повара на использования этого сыра и может ли он запустить механизмы и открыть дверь для выдачи сыра (например у нас электронный замок которым управляет система и холодос в онлайне)
Итого, У нас валидация разделяется на типы: бизнес валидация, валидация безопасности, валидация уровня инфраструктуры (в сети ли холодос и может ли открыть замок)
Вопрос: Где проводить валидацию?
1. На уровне контроллера
2. На уровне сервиса
3. На уровне бизнес модели (если да, то как не смешать слои?)
4. Валидировать на каждом уровне свою ответственность (если да, то как не размазать сам контекст всего действия?)
разная валидация в разном месте. Зависит от того, какую предметную область мы описываем. Агрегат и входящие в него сущности и объекты-значения отвечают за валидацию бизнес-инвариантов. Domain services могут осуществлять валидацию, которая распространяются сразу на несколько агрегатов, но нужно быть аккуратным с транзакционностью. Application services обычно как раз отвечают за аутентификацию, авторизацию и т.п.
Например, разные права можно описать разными типами: Шеф-повар и просто Повар. У них будет разный интерфейс, однозначно определяющий набор доступных операций. Плюс нужно будет подумать крепко, является ли Шеф просто Поваром, то есть нужно ли здесь наследование. Это как раз хороший пример, когда имеет смысл пообщаться с бизнесом и спросить: А может ли вообще шеф выполнять работу обычного повара?
Если же у нас какой-то мощный DACL и attribute-based authorization, то проверку желательно вынести в отдельную службу и эти службы уже использовал в операциях бизнес-моделей. Но связности и нарушения инкапсуляции здесь уже не миновать. Вообще, инкапсуляция - штука очень контекстная. Так слой доступа к данным должен уметь заглядывать в private поля и свойства, чтоб положить данные в хранилище.
На все 100% согласен с утверждением "У меня было программирование до DDD и после". Я всем знакомым говорю так: "Я как разработчик до DDD и после это два разных разработчика". Эти принципы кардинально поменяли мой взгляд на программирование.
*_Надеюсь доживу до того дня, когда увижу в названии нового видоса "Язык ассемблера....."._*
*_Ну и по классике вопрос: -Айтиборода, где ассемблер?_* 😂
Полностью согласен с тем что тут обсуждаете по DDD)
Инварианты и программирование по контракту пришли от Бертрана Майера
Bounded Coxtext DDD = SRP Дяди Боба
Рано или поздно начинаешь замечать где и какие принципы заложены)
Берг Джонсон, Деоган, Савано «Безопасно by design» - все основные тезисы применимости DDD, но через призму безопасности кода.
1:23:00 может дальше будет объясняться. По идее сервис нужен для того, чтобы не привязываться к инфраструктуре. То есть может быть веб контроллер (с гетом), консоль контроллер (с параметрами) и дальше уже на что фантазии хватит
Ох, все на самом деле куда сложнее, чем тут рассказывается))
Я не могу отделаться от мысли, что всё это сводится к идеям из Grokking Simplicity, точнее к трём вещам:
1. Данные (Data): факты, которые могут использоваться как угодно.
2. Функции-расчёты (Calculations): когда на любой вход, у нас одинаковый выход. В видео это называли без side-effect'ов.
3. Функции-Действия (Actions): что угодно зависящее от того, когда было вызвано или сколько раз.
Любое действие "заражает" всё что выше. В примерах это было ActiveRecord, вызов функции now () и т.п.
Сильная связность и слабое сцепление, а не "зацепление", от слова цепь.
Здорово.
Борис немного напутал с unit of work (UoW), от того он и сказал что "не знаю почему его так назвали"
UoW отвечает за то чтобы изменения сохранялись атомарно, от того он так и называется
а то о чём говорил Борис (холодильники с одним id будут одним и тем-же холодильником) -- это Identity map
Спасибо!
респект за PHP
Боря, привет!
Еху
оригинальную книгу DDD Еванса не осилил... Но сейас вам расскажу про DDD...
Рассказал про 1с и предметно-ориентированное программирование)
Даня Поперечный отжигает про ДДД😀
Мне 36 лет я инженер-конструктор на 1:22:00 я подумал "да ну нахрен, я пошел" но все же досмотрел! Правда у меня есть образование программиста, но в 2007-2011 году у меня с этим не задалось! Спасибо за видосы
Как раз на новом проекте столкнулся с ДДД, сейчас в процессе изучения этого подхода, видос вышел прям в тему и вовремя для меня) спасибо!
Наверное моё ИМХО, но про ДДД без вайтборда рассказывать нельзя))) Мало внимания было уделено immutable. И объяснение UoW мне, как шарписту, совсем не понравилось. В целом, гут, чел без заготовленного текста рассказал сложную тему. Но, ведь ДДД не сложный, если рассказывать, не прыгая с место на место ;)
О да, спасибо за понимание! Я пытался убедить лекса дать доску, но сошлись что "формат не тот". А вот то, что он "не сложный" зависит от прогресса :)
Елки палки, год назад когда смотрел было все жоско страшно, но сегодня я все сказанное понял.
Растешь)
Чувак умный но зря он не читает книги, я раньше как он делал но потом понял, что нудная теория очень важна
Очень крутой гость! Читал 45 татуировок менеджера, и надеюсь что будущему владельцу этой книги она очень понравится и поможет развиться :)
очень плохой выпуск. думал намного лучше будет.
"у нас всё в модели, но правда есть ещё просто сущность, а есть ещё сервис..."
и на примере пицерии, ага... реально вопросы подхода "анемичной против жырной модели" актуален для автоматизации/моделирования чего-то сложного типа большой фирмы.
Пушка. Соскучился по твоим интервью, и тема как раз актуальная. У меня сейчас процесс трансформации в DDD как раз :D
Весело было :) Классное интервью! Отличный собеседник!
Коллеги, выскажу своё скромное мнение, DDD это круто, когда умеешь его готовить, но готовить как Борис мне не нравится. У этого парня отсутствует понимание связности процессов. Он для приготовления пиццы делает одну модель про холодильник, а для обслуживания холодильника другую. Нельзя управление над сущностью разносить. Он теряет связность и прозрачность управления (всё в одном месте). Как готовить пиццу, если холодильник на обслуживании? Ну и т.д.
Также не услышал в интервью зачем Борис использует репозитории, хотя Лекс спрашивал. В этом тоже собака порылась, ну не понимает корней или ловко уклоняется Борис от ответа.
Не надо готовить "как Борис". Это был поток мыслей экспромтом :) Больше реклама DDD нежели учебник. Проследуйте, пожалуйста, по ссылкам под видео (или где они там), если хотите учебного материала
> Он теряет связность и прозрачность управления (всё в одном месте).
Абсолютно с Вами согласен. Разбивать "ради разбивания" не стоит. Я пытался (видимо, не удачно получилось) показать как работают BoundedContext. Если говорить про микросервисы, то один BoundedContext - это микросервис. В монолитах это модуль (или пакет)
> Как готовить пиццу, если холодильник на обслуживании?
В моем примере этого не было. В моем примере (там... кхм.. я заказчик :D внезапно ) кухня и ремонт никак не связаны, кроме факта очистки холодоса. Например, "готовят из первого доступного холодильника"
Вообще, если такой вопрос встает (как готовить если на обслуживании) то нужно спрашивать у заказчика. Может действительно оказаться, что это крайне связанно, и никаких раздельных контекстов тут нет. В моей практике такое встречалось - что когда код "не ложился", подсвечивали это продукт овнерам, и овнеры осознавали, что у них кривые требования, и они их меняли
Спасибо за фидбек
Борода, спасибо за видео. Теперь смогу с легкостью Эванса дочитать ) Не хватало общего понимания без кучи деталей, из которых и состоит книга. level up )
А еще придется рассказать команде, что у нас личинка DDD, но никак не DDD )
На мой взгляд, можно читать только bounded context. Сам Эванс через цать лет после первой книги сказал, что это ключевая идея. И если писать вторую редакцию, то именно это будет центральной частью.
@@evgenyamorozov И Вон Вернон написал книгу именно с учетом этих мыслей)
DDD, TDD, DDT, ЧТД - главное не перепутать
Я бы в 1с эту пиццерию сделал))
Зачем холодильнику знать про пиццу?
История со стеклянной дверью и кофе очень знакома))
Шикарное интервью. Я прям чувствую как прокачиваюсь.
В зависимости от реализации, конечно, но MVC может провоцировать technologically partitioned структуру проекта, в свою очередь, DDD провоцирует следование в сторону domain partitioned структуризации ваших модулей.
А разве DDD не занимает только М из MVC? Правда, в таких проектах чаще 4 слоя. Слой предметной области, слой инфраструктурной области, сервисный слой, слой приложения.
@@КлинокСтальной Люди по разному понимают DDD, у кого-то действительно доменный дизайн это только часть модели из MVC. У других MVC используется внутри закрытых контекстов. Что стоит понимать под МVC? MVC паттерн может быть использован в бизнес логике домена для своих внутренних целей разделения контроля за производство отображений.
Третьи понимают под DDD методологию, придуманную проблемными аналитиками, чтобы они поимели ощущение причастности к разработке.
Мне показалось, что в видео DDD было маловато (читал только сине-зелёную книжку Вона Вернона). Немножко прошлись по ограниченным контекстам и единому языку, немножко по агрегатам (но объяснение крайне расплывчатое на мой взгляд). Что касается богатых и бедных моделей, то богатые модели предпочтительнее и крайне рекомендуется, если использовать DDD, но их отсутствие вполне сочетается с подходом. Большая часть видео скорее про архитектуру лука и изоляцию логики. Часть про репозитории интересная, но напрямую не касается DDD и onion architecture.
У меня пока сложилось впечатление, что DDD - это больше про проектирование (создание правильной концептуальной модели с событиями, агрегатами) и привлечение бизнес-экспертов в твоё проектирование. Поэтому был удивлён, что заказчику не нужно продавать DDD.
Вот это контент подъехал! то что нужно!
Клевый парнишка
Хорошо обьясняет
Но понимаешь, когда сам имеешь этот опыт
на самом деле, очень плохо объясняет.
ДДД и Single Responsibility вышло из чата
Привет! У тебя очень крутые интервью! Очень прошу, может найдешь на интервью человека, который занимается VR? Мне кажется очень интересное направление, многим зайдёт
Плюсую, тоже было бы очень интересно послушать)
Честно говоря, как-то не кажется это DDD облегчающим сложность программирования....
Я ничего не понял. Но научился готовить пиццу.
На словах вы Лев Толстой, а на деле?.. Парни лучше бы пример про холодильник в коде показывали и писали, лучше было бы понятно
Этого добра в инете навалом
поддерживаю идею приходить в универы послушать лекции! вот это реально было бы круть! хотя бы пусть бы онлайн трансляции сделали, можно платно. огонь тема!
Уже года как 2 есть трансляции
Скажите, Борис, а где можно ознакомиться с примерами вашего кода, в котором применен DDD, не обязательно реальный, вполне сгодится чтото вроде пиццерии с холодильниками.
я искал как печку на машине почистить, как я на это наткнулся????
Ха-ха-ха)
Надо было 1сника пригласить на пару. Они бы поняли друг друга
PHPшники как получают достаточно знаний сразу же начинают думать о изоляции всего и везде))
Про DDD лучше возьми интервью у Владимира Хорикова: Борис Беньковский пока еще не разобрался в теме )