Организованное программирование

Друзья, привет. Это подкаст Организованное программирование. С вами Кирилл Макевнин, бессменный ведущий. И у меня сегодня в гостях тоже Кирилл Витчинкин. С Кириллом мы будем обсуждать тему ДДД. И когда, соответственно, я смотрел в то, там кого позвать, вот я нашёл Кирилла как человека, которого, во-первых, мне все рекомендовали. И Кирилл достаточно широко известен в кругах специалистов и любителей ДДД. А, программист с большим опытом, архитектор. И, как Кирилл рассказал, я увидел у него тоже на сайте, он, в общем, занимается созданием курсов, так что мы в каком-то смысле коллеги. Вот. Потому что я этим занимаюсь чуть подольше, но, в общем-то, мы в одной сфере сейчас этим всем добром занимаемся. И, э, сегодняшняя тема у нас ДД. А я надеюсь, мы очень весело и задорно про неё поговорим. Кирилл, привет. А, всем привет. Смотрите, мы с вот с ходу прямо не до конца не знаем, например, по аудитории, насколько ДДД является темой, которую люди, которые нас смотрят, да, они её знают. Поэтому, а, с одной стороны, нам не хочется падать прямо вот в определение, типа: "Кирилл, расскажи, что такое ДД", и мы начинаем с тобой, значит, разбирать. Этого, во-первых, добра полно. Во-вторых, а это будет не очень весело, поэтому мы попробуем заходить за реальной историей. Тем более ДДД не сегодня появилась, да, и были волны как бы интереса, как и многие другие вещи, потому что вот мы сейчас с тобой до старта начали об этом говорить, и ты говоришь: "Вот сейчас типа интерес просыпается", а мне, знаешь, какое-то дожавю, потому что я это уже много раз проходил за свою карьеру, когда, знаешь, как некоторые люди вот сейчас говорят: "О, просыпается интерес к функциональному программированию". Я такой: "Мы в двенадцатом году там фанатели от него, да, потом оно раз ушло, потом снова появляется". И вот здесь примерно такое же ощущение. Поэтому, наверное, первый вопрос, который я тебе скажу, ДД как концепция появилась довольно давно. Прошло много лет и не произошло такого, честно говоря, что все такие: "Ну вот как бы как ты разрабатываешь?" Ну вот ДД вообще вот прям полюбас. Более того, мы даже знаем отрицателей. Например, гошники очень часто вообще они там всё отрицают и у них вообще типа не так. Что как ты вообще видишь картину с ДД? Что случилось? Что произошло? Где вообще его место в этой жизни? Или мы все в нём нуждаемся, но просто не понимаем? И сейчас мы с тобой всех осветим. А почему он стал снова популярным? Скорее даже это стало какой-то нишевой историей или это такая же история, которая всем нужна, но просто не все её понимают. Или, например, мир изменился, мы как-то вообще по-другому пишем софт и всё это. Угу. Ну здесь, скорее всего, два правильных ответа, да, вот из трёх, которые ты озвучил. Первое, почему ТД обрело вторую жизнь, да, потому что появились микросервисы, да. И вот если мы посмотрим на момент, когда они появились, да, там пятнадцатые, шестнадцатые, там семнадцатые года начались активные внедрения в России тоже как бы захлестнул волной там в пиктехе чуть позже все начали делать это микросервиса. И вот как сейчас помню, что приходишь на любую конференцию там в семнадцатом-восемнадцатом году, и там выходят люди на сцену, а у меня 1.000 микросервис, у меня 2.000, у меня 3.000, 5.000, и у кого больше, тот круче. Вот. Но со временем, да, люди стали понимать, что чем больше сервисов компаний, тем сложнее их обслуживать, да, потому что, ну, просто много инстансов, это занимает определённо больше трудозатрат. И критерий крутости, да, когда у меня их много, он уже перестал таким быть, да, критерий крутости стал, что у мне их ровно столько, сколько надо. И вот вопрос, да, а сколько их надо? И вот здесь люди как раз задумывались, а каким образом вообще на эти сервисы нарезать? Есть ли какие-то методы, подходы, практики? И вот как раз, когда люди обожглись, наступили на грабли, Uber даже выпустил свою знаменитую статью, да, где они признали, что они там несколько лет нерали микросервис неправильно. Теперь разработчику нужно там шесть-7мь сервисов потрогать, чтобы какую-то фитю сделать, и он тратит на эту умо времени. Они запустили проект по наоборот сокращению количества микросервисов, да, и вот здесь как раз ДДД и обрёл вторую жизнь, да, потому что ДД стратегические паттерны - это как раз ответ на вопрос, как правильно нарезать систему на микросервиса. Вот. И поэтому люди уже поняли, что теперь они не просто создают сервисы, потому что могут, да, а начинают это делать осознанно через стратегические паттерны ДД. И там есть как раз конкретная формула, как мы должны находить баун контексты, субдомены, ну, и дальше уже идти к микросервису. Вот поэтому ДД началась вторая жизнь, потому что сейчас люди как раз стараются это делать осознанно. Вот. Э, и что касается всем это надо или не всем надо, ну, это всё зависит от задачи. Вот, э, на мой взгляд, э, подход недотоцнён, он сложный, и на практике разработчик к этому приходит просто чуть позже, да, то есть условно, чтобы тебя взяли на позицию джунала, тебе не надо знать дд. Вот нужно знать язык программирования и в целом этого достаточно. Вот. А ДД - это то, когда у тебя уже возникают сеньорная компетенция. Тебе приходит руководство, говорят: "Создай новое приложение с такими-то характеристиками. Ты его создаёшь, оно плохо работает, ты понимаешь: "Ага, наверное, я как-то не так что-то сделал, да, как-то не так логику по слоям распихал". И вот здесь уже называет вопрос: а как мне её правильно распихать? Да, и в ходе анализа литературы мы как раз приходим к ДД. Вот поэтому это просто такая стадия Senior п, скажем так. где мы это применяем ДД. Вот Джуны зачастую про это не задумываются. Вот поэтому она не так популярна, этот подход. А буквально перед тем, как мы с тобой созвонились, я смотрел видос, ну, быстренько просматривал, комментарии читал. Как его ещё раз зовут? Хонов, да, по-моему, я боюсь ошибиться. Влад Хонов. Хононов, точно, Хонанов, да. А я, кстати, хотел и с ним поговорить, потому что его тоже рекомендовали, но просто он буквально недавно с этой темы уже выступал. Я такой: "Так, значит, надо всё-таки разнообразить эту историю". Но я почитал комментарии, там, ну, всегда приходят ребята и говорят: "Вы не правы во всём, всё не так". И там было интересный поинт, видно, что человек разбирается, ну, такой довольно большой обстоятельный комментарий написал. И одна из примеров он там писал, что типа: "Ребят, ну, э, ДД же вообще не про микросервисы". То есть это как бы одна из имплементаций. И у тебя сама идея того, что там делается, да, вот те вещи, которые мы сейчас с тобой в том числе будем обсуждать, они в этом плане ортогональны. А, но ты говоришь, что как как бы как будто ты говоришь, что вот именно микросервисам нужен ДД. Для определения границ микросервисов, да, нужно ДДД. Вот. Угу. Ну, изначально как бы, ну, во-первых, у ДДД есть как бы есть как ДДД, как философия, ДДД как стратегическая история, да, про то, как мы нарезаем компанию там на направления, на какие-то субдомены, на какие-то бизнес-направления. Есть тактическое, да, как мы пишем код. Вот поэтому здесь вот я на три части это делю. Угу. Философия - это вот про как, не знаю, там какая-то аля религия, да, там стратегия - это как бы наш план на всю компанию. Тактика - это как условно конкретный разработчик пишет код. Вот когда мы говорим про микросервисы - это стратегическая история. Вот. И когда мы говорим про разработку монолитов, больших монолитов, это тоже стратегическая история. И вот здесь ДД у них есть конкретная рекомендация, да, как нарезать монолит на модуле, как нарезать соответственно модуль, вынесенный в отдельное приложение - это микросервис. Вот поэтому мы и говорим про микросервиса. И на текущий момент, да, индустрию что волнует, да, волнует именно вот сейчас все разрабатывают в микросервисах. И вот здесь как раз ДДД и, скажем так, начинает всплывать, да? То есть, конечно же, ДДД без микросервисов может быть. Тдд в монолите, ДДД, в принципе, как философия, но конкретная, скажем так, на сегодняшний день точка боли, да, которая у всех есть, которая ДДД решает, это вот как раз нарезка на микросервиса. Вот как минимум применять тактический паттерн внутри микросервис или нет, это уже отдельная история. Это, ну, смотря какая есть задача, смотря какие есть компетенции у команды, хочет она это, не хочет и так далее. Это отдельная история. Но если говорить про именно стратегическую историю, нарезку, да, сколько нам нужно сервисов, 100 или 10, вот здесь ДД 100% нужно применять. Угу. О'кей. Мы, кстати, про все эти моменты поглубже поговорим. Но теперь, чтобы переходить как бы к следующему этапу и всё это обсуждать, давай немножко тогда с философической точки зрения поговорим, потому что слово много раз мы говорим, вот применяется, применяется. Теперь всё-таки поговорим, о чём это, то есть о чём и идеально будет, если мы это попробуем рассказать на сравнении. То есть, грубо говоря, вот у тебя есть человек и он без ДД, а вот есть рядом с ДД и как, знаешь, в рекламе, а, значит, смотрите, наш порошок работает лучше. Что происходит? Да, в чём философия, с чем сталкивается разработчик? Угу. Мы со стороны уже ближе к разработке сейчас идём, да, получается. Ну нет, давай сначала действительно общее философичное. Просто тогда не будем много сильно глубоко погружаться, типа общая концепция, общая проблематика. Угу. Ну, общая проблематика, да, то, что в целом если мы говорим про начало разработки какого-то IT-проекта, всегда возникают вопрос, от чего мы его будем отталкивать, да? У нас есть подходы там database FST, да, условно мы там в первую очередь думаем про то, как мы будем хранить данные, а потом уже думаем, как мы будем выстраивать доменные модели, логику, само приложение и так далее. Есть там API F, да, где мы сначала думаем про API, потом думаем про всё остальное. В общем, там разно есть много подходов, да, суть этих подходов в том, с чего мы начинаем вообще э разработку приложения, от чего мы отталкиваемся. И вот, э, что API, что database, да, это подходы, где мы фактически отталкиваемся от инфраструктуры, да, от средства хранения либо средства интерфейса, да, которые мы будем предоставлять. А DDD оно говорит, что типа это всё класс, но концепция другая, да? Вы же, ребята, что делаете? Вы автоматизируете какие-то бизнес-процессы, да? То есть есть бизнес, у него есть какие-то задачи, и вот вы как разработчики, вы их как бы автоматизируете, да? По сути, мы этим занимаемся. Если мы возьмём любой там marketкеплейс, банк, IT, там нужно, чтобы просто эту рутину автоматизировать. И, соответственно, требования - это бизнес-правила, да? Поэтому почему же вы отталкиваетесь от базы данных или это API? Вам нужно отталкиваться от бизнес-правил, от предметной области, да? И DDD как концепция, оно стоит во главе угла то, что предметная область и понимание предметной области - это самое главное, это то, от чего нужно отталкиваться. Как только мы её поняли, поняли бизнес-правила, мы уже идём к построению доменной модели и уже конкретно имплементация. А потом, как мы это будем отдавать через API или как мы это будем хранить, это уже дело десятое, да, потому что мы можем использовать любую базу данных, можем использовать HTTP, JPC, Swap, GPQL, всё, что хотим, можем использовать, но сама предметласть, она первостепенна в компании. Если разработчик её не понимает, вот если он не умеет её грамотно закодировать, то приложение, как бы мы классно не выбрали базу данных, как бы бы не классно вы не выбрали API, оно всё равно будет страшненьким и его будет очень сложно поддерживать. Вот это вот основная идея DDD, а это разработка от понимания предметной области. А можно я адвокатом дьявола побуду? Ну, потому что если бы, грубо говоря, эта штука была такой прямо прозрачной, понятной, простой, у тебя бы разработчики в какой-то момент это прямо чётко чувствовали, такие: "Ой, а я недоразобрался в предметной области, и из-за этого у меня получилась фигня. Ну и причина-следственная связь приводит его к пониманию". Но то, что ты говоришь, очень неявная вещь. Почему? Потому что я, например, не могу себе представить, что разработчик вообще не понял, что он делает и просто делает. То есть у тебя, как правило, с начинается всё ещё более приземлённо с, ну, чуть ли не с макетов. Тебе говорят: "Мы делаем marкетплейс. Вот у тебя макеты, вот у тебя каталог, вот у тебя корзина, вот у тебя это". И сказать, что разработчик на этом части такой думает: "Ой, я вообще не понял предметную область, я не могу, честно говоря". Мне кажется, он вполне себе внутри понимает, что у меня достаточно знаний, если он квалифицированный, да, чтобы это реализовать. Он, конечно, вперёд может не предвидеть. у него, может, опыта нет создания маркетплейсов, он не будет понимать все архитектурные проблемы, которые там всплывут, но он явно будет думать: "Ну, наверное, там производительность, наверное, там вот тут вот, не знаю, какие-нибудь рекомендации. Сейчас ещё Иишка, да, там подплыла, вот, вот это всё". Но в целом он как бы возьмёт и будет делать. И если у него будут возникать какие-то проблемы, я прямо уверен, он не скажет: "Ой, я тут не додумал по предметной области". Он, скорее всего, если это случится, он скажет: "Ну, а как я мог заранее знать то, что вы придёте ко мне с требованием подключить пять разных платёжных систем". Я на это не рассчитывал. То есть как будто бы вот вот такой вот у меня к тебе вопрос. Ну да. Смотри, тут какой нюанс, да? Вот ты сейчас это обсуждал, да, и ты сказал несколько инфраструктурных вещей. Платёжный сраз ишка, а и что-то там ещё, да? То есть по сути ты ничего не сказал про поведение. Вот ключо момент, да, в DDD и вообще в принципе OP, да, в целом, что такое DDD? Это ОП на стероидах, по сути. Это старый доллар ОП. Просто вот когда нам не просто какие-то абстракции, да, говорят в книжке, что есть там наследование, полиморфизм, ещё прочие вещи, капсуляция, это вот конкретное решение, как делать тактические конкретные, скажем, сущности, то есть конкретные рекомендации. Вот если мы говорим про тактику и э в целом, да, когда мы говорим про DDD и про доменную модель, да, мы не просто думаем там, а будет у нас там и, не будет у нас и ещё что-то, мы в первую очередь думаем о поведение, да, то есть какие у нас должны быть сущности в доменной модели. какое у них будет поведение, какая будет логика, где мы эту логику расположим, да, и так далее. Вот. То есть мы смотрим, какие у нас есть юзкейсы, да, в той задаче, которую мы реализовываем, и какие нам нужны модели, да, доменные объекты, которые будут, собственно, эти юзкейсы исполнять. Вот поэтому, как на практике происходит, да, разработчик понимает логику, он понимает, что есть какие-то сущности, но эту логику располагает просто в сценариях, да, то есть он делает такие большие длинные процедурные сценарии. вюзкейсах зачастую, а сами, скажем так, модели, да, которые участвуют в этом сценарии, они анимичны. То есть это просто вот такой термин из ДД мешок с полями. Это просто дтошка с какими-то полями, она ничего не делает, у неё такое поведение. И вот этот сценарий над ней просто манипулирует. Вот получится ли такое приложение запустить? Да, получится, она будет работать, нет проблем. Ну, тут возникает вопрос, насколько легко будет этот сценарий поддерживать, который может быть длиной с три экрана, а в котором будет куча логики, слабо связаны с друг другом. Вот это будет сложно тестировать, сложно развивать и так далее, да? Если же мы возьмём принципы ДД тактические, да, и эту логику расположим в каждой какой-то маленьком объектике, то он маленький, его легко тестировать, а он не лазит в инфраструктуру, соответственно, его можно тестировать юниттестами, дешёвым, быстрыми. Ну и плюс можно во всём приложении использовать тоже. Соответственно, это переиспользование и снижение дублирования. Ну и в итоге мы получаем тот же результат на финише, да, тоже работающее приложение, но эффект он накопительный в долгосрок, да? Ну, то есть, если мы возьмём два проекта, написанные в стандартном там процедурном подходе, да, там, где у нас там анимичные дтошки и в ДД, то и посмотрим на ОО проекта через год, да, то стоимость поддержки того, которая написано ДДД, будет сильно ниже, чем стоимость поддержки того, которое написано вот, э, с анимичными ДТОшками. Вот. И, соответственно, это инвестиция в долгосрок. Если мы делаем какой-то разовый проект, да, там, конечно, не нужно заморачиваться с ДД, да, вы его там выкинете через 3 месяца и и забудете. Если это проект серьёзный, со сложной логикой, со сложной предметной областью в долгосрок, да, то здесь ДД будет показывать результат. Вот, будет показывать его накопительно спустя время. Вот на старте, конечно, там вложиться придётся чуть больше, чем если сделать простое крут приложение. А если вот верну сейчас ты немножко чуть дальше пошёл в глубину, да, вот чуть-чуть назад вернуться. Когда ты говоришь про поведение, я же как раз имел в виду, что у тебя всё это происходит, ну, по сути, на мокапах каких-то, да? То есть тебе продукт приходит, говорит: "Смотри, мы, ну, понятно, что он не с нуля такой: "Мы придумали что-то, человек же на работу устроился, значит, он уже знал, куда он попал", да? То есть у тебя чёткая история. Вот мы, например, создаём там, не знаю, Marketplйс, и ты поведение всё по сути видишь из в картинок. У тебя как бы продукт, он с дизайнером работает, он на уровне кода вообще не мыслит, и у тебя, соответственно, вот картинки, вот переходы, вот поведение. Понятно, что что-то там дополнительно либо словами объясняется, либо текстом, но я имею в виду, что это вот куда уж бизнесовей, то есть сам бизнес именно так и делает. И на выходе, соответственно, разработчик двигается дальше. Но ДД же оно же не только то, что а ну ладно, о'кей, я пошёл сейчас в объектах это у себя там разобью, анимичная модель, надо, значит, Ричмодель делать, все дела. Он же ещё на уровне бизнеса пытается что-то сделать. И вот я именно на этом уровне пытаюсь как бы сначала обозначить, то есть чувак, который без ДД, чем он будет отличаться от чувака, который с ДД, потому что глобально как будто бы, если что-то специально не делать, ну, мы все так делаем. То есть к тебе приходят с макапами, ты позадавал вопросы типа: "А, о'кей, а вот эта кнопка к чему приведёт? А, э, модалка будет или это? А вот если я, например, заказ делаю, у меня в это время там что-то уходит в платёжку, ну, и так далее". То есть миллиард всяких вопросов, которые, в принципе, любой а сеньор задаст. Угу. Да. Ну, зачастую, скажем так, нам приходит ТЗ, в котором, э, просто написано, что надо сделать. Вот. И ключевой вопрос как раз вот задаст вопрос или не задаст, да? Кто-то просто побежит э делать, как написано, да, кто-то начнёт задавать вопросы. Вот человек, который имеет компетенции ДДД, он, скорее всего, начнёт копать глубже, задавать вопросы, да, потому что у него будет потребность построить доменные модели с доменными сущностями, да, и у них должно быть какое-то поведение, и он начнёт выяснять, да, допустим, если мы там у нас платёжная модалка, да, мы зададим вопрос, да, как мы будем комиссию считать, да, какие есть формулы и так далее. Вот. И с точки зрения реализации, да, оба разработчика так или иначе к этому придут, да, но человек с компетенцию ДДД, он задаст больше вопросов. Вот он глубже копнёт. Возможно, он перешагнёт через ТЗ, перешагнёт через аналитика, придёт к стейкхолдеру и вместе с ними это всё обсудит более глубоко, да? То есть, если мы говорим, допустим, про такую вот практику на Шторме, которая близка к DD, да, на сегодняшний день она как раз основная её концепция в том, чтобы типа не надо писать ТЗ, как бы условно, если у вас есть какая-то область, которую вы хотите поисследовать, конечно, можно посмотреть аналитик, который будет там всё дотошно описывать, но скорее всего он это опишет в силу своего понимания. Вот. Давайте лучше соберёмся с заказчиками, всё это прорисуем, продумаем, а, обсудим по 10 раз. И, ну, не по 10 раз, разрисуем модель. Разработчики всё поймут, да? Мы поймём, как устроим процесс, из каких сущностей он состоит, как они себя ведут, и уже потом пойдём в разработку, да? Потому что я вот часто был кейс, да, я много работал в заказной разработке, да, приходит человек и говорит: "Вот тебе ТЗ, делай". Ты начинаешь делать, сделал. Потом проходит 2 недели, он говорит: "Ой, а тут ещё комиссия, оказывается, в платежах есть. Давай ещё сделаем". Ты делаешь ещё раз, третий раз, четвёртый раз делаешь. Потом ты понимаешь, что ты просто тратил деньги компании, свои деньги несколько раз. Почему? Потому что ты просто не раскрыл предметную область до конца. Ты двигался итеративно, как сейчас это модно. Ты двигался по ТЗ, но в итоге концепция была изначально не раскрыта. предметно область непонятна, и мы делали много исправлений со временем. Вот поэтому человек с ДД, он просто начнёт больше задавать вопросов. И вот моя ошибка на, ну, как я бы её справил на то время, да, я бы сказал: "О'кей, давай мы посмотрим все задачи, которые ты хочешь мне дать, и потом уже начм делать первое". Тут не могу такую вещь не сказать. А в вот если уходить с уровня идеального мира, где все пытаются сделать всё хорошо, на уровень реального мира, где у разных людей разные задачи и далеко не все эти проекты про то, чтобы сделать хорошо, когда мы говорим про заказную разработку, не будем показывать пальцем, и у тебя получается, э, что вообще не факт то, что это нужно или я не прав? Ну, я имею в виду, понимаешь, да, о чём речь, что аутсорсер, вот он это делает, и он такой: "Блин, мои ребята там надо, чтобы они шли, задавали вопросы". Скорее всего, кстати, это может родить ведь ещё и негатив, потому что скажут: "Мы вам дали ТЗ, хорош с нами пререкаться, делайте". Ну, здесь здесь, мне кажется, ну не совсем, скажем так, это политическая история про как там заказная разработка работает. Мне кажется, это немножко за рамками нашей тематики обсуждаем, да. Вот. И я всё-таки отталкиваюсь всегда от того, что разработчик он хочет сделать хорошо заказчику. Вот. И он хочет писать качественный хороший код. Вот я, ну, как сам всегда, так разрабатывал так и ну такое вот мировоззрение. Поэтому, чтобы специально там разрабатывать плохо, чтобы потом на какие-то доработочки нам там это заказики сделали. Вот. Но это уже политика. Я думаю, что её не стоит обсуждать. Не, ну смотри, реальная жизнь всё-таки реальная жизнь. Я не к тому, что кто-то плохо делает, а просто установка. Я могу по сво по своей истории сказать. Знаешь, как бывает вот это вот когда мы пользуемся каким-то сервисом, да, и у тебя ребята, которые, ну, не знаю, там парикмахер, кто угодно может считать себя слишком умным и который и врачи тоже, да, которые знают очень много, и эти люди будут слишком много пытаться там советовать, рекомендовать, куда-то переучивать. На самом деле это не всегда людям нравится. Я вот про что. Я скорее не про то, что там кто-то хочет плохо сделать, а про то, что с этой историей, давайте я сейчас тут всё разбегусь, пойду к вам, обойду все там слои и самое идеальное всё сделаю. На самом деле можно раздражение таким образом легко вызвать. И а меня, например, в этом плане американская медицина как бы с одной стороны лучше, а с другой стороны хуже. Вот, например, ты идёшь в России к доктору, да, он, как правило, тебе пытается помочь, рассказать и объяснить, чтобы ты глупости не делал, типа, чувак, ты вообще не того хочешь, тебе это надо часто, да, и это на самом деле классно часто срабатывает. Но иногда не очень. И вот, а в Штатах наоборот, у тебя в Штатах вообще никогда доктор никакой ничего тебе не скажет. Ты пришёл, говоришь: "У меня болит". Он тебе не скажет: "О, да у тебя системная проблема, тебе надо вот это, вот это, вот это". Он просто по правилу говорит: "Придёшь в следующий раз". И из-за этого часто, например, наши ребята здесь, они очень не любят для лечения каких-то системных вещей ходить по американским докторам. А у них, чтобы ты понимал, это не их желание. У тебя там суды, у тебя там эти страховки, они просто все страхуются. Они никогда в жизни о этом не говорят. И поэтому, если ты хочешь вот такое же поведение, про которое ты говоришь, ты должен идти к людям с своим менталитетом, которые даже в обход правил так сделают. Не то, что это прямая аналогия, но я просто к слову, что есть вот реальная жизнь, она может быть вот такой. То есть слишком умные ребята тоже иногда создают проблемы, когда не надо задавать лишних вопросов. Ну, может быть, ты с таким меньше сталкивался. Я не знаю, как в своей практике. Типичный кейс, да, с которым мы сталкивался. Что, допустим, я работал в брокерской компании, да, то есть, ээ, финансовый рынок, аэ, брокер - это достаточно сложный в целом предметной области. И вот если взять любого разработчика, да, то не факт, что он там понимает понятие, что такое стакан, что-то такое инвойс там и так далее. И вот ты приходишь, э, тебе говорят: "Ну давайте сделаем стакан". Ты такой: "Э, о'кей, я что это такое?" И есть аналитик, который в целом тоже также в эту, ну, на эту, скажем так, работу прошёл год назад. И он такого же примерно понимания, что такое стакан. Вот он как-то может тебе на пальцах объяснить, что это такое, но ты понимаешь, что это как бы, ну, весьма поверхностно, да, но чтобы сделать что-то, ты хочешь разобраться, да, есть трейдеры, да, которые торгуют каждый день, есть люди, которые консультируют клиентов, да, и он говорит: "А, слушай, вот у нас есть парень трейдер, он это вообще шарит за эту тему. С команды идёшь к нему, он тебе всё разрисовывает, объясняет, куда, куда, как. Всё, ты всю модельку разрисовал, вопросы ему задал, всё, теперь смапил у себя в голове с тем ТЗ, который тебе принёс аналитик, и пошёл сделал осознанно хорошее решение. Вот. Вот вот вот это хороший пример, как люди, которые понимают в DDD, да, которые умеют общаться с заказчиками, как они могут это принести себе пользу этой практикой. Вот. То есть мы там не бегали по всей компании туда, куда не надо, но когда возникала какая-то конкретная проблема и у нас был человек, который готов нам помочь, мы вставали, шли и общались с ними. И потом думали, как эти бизнес-правила, которые он озвучил, да, наложить на конкретные классы, методы и так далее. А если у тебя, да, я потом ещё спрошу по языке, в которых нет классов. Ну ладно. А знаешь, я мне кажется, что здесь выпускается всегда. А просто сразу, кстати, ещё слово скажу. Я был человеком, который тоже там заморачивался до DD там много всем за свою карьеру. И, э, Evнс у меня там где-то Нет, я его отдал уже. А смотри, какая ещё есть история. Вот если мы берём, э, там типа аля девяностые, у тебя, помнишь, была очень популярная история про экстремальное программирование и до сих пор про это часто говорят. И вообще многие вещи оттуда везде разошлись. И там очень классная вещь была всегда в экстремальном программировании. Заказчик всегда рядом. Помнишь, да, такую концепцию? Её идея не в том, что ты с вот как сейчас ты говоришь, ты общаешься там с продуктом, с аналитиком, с бизнесом, а там было смещение как раз на пользователя, потому что все эти ребята, они, конечно, молодцы и очень умные, но если у тебя, например, там банковский софт, ты делаешь, есть конкретный человек, который сидит, ну, B2B, допустим, да, и управляет вот этим всем кабинетом, ну, для того, чтобы вот вытащить все эти вещи и реально юзкейсы, понять изменения, ты должен быть с ними. И у меня как раз была такая история очень классная. Значит, была такая компания, она сейчас переменована Петр Сервис в Питере. Они занимаются вот биллинг Мегафона. Они делают на самом деле не только Мегафона, то есть это ребята, которым больше 30 лет. То есть вот они первые биллинги в России делали ещё в СССР, наверное, даже. А вот и это очень большая сложная компания со сложной структурой, с очень сложной логикой. Сам понимаешь, там это вообще безумие там. Это, кстати, вот это вот телекомы, они вообще есть есть целые стандарты там того, как вот это всё бьётся. То есть всё, что мы сейчас с тобой рассказываем, там просто разложены, там книги по этой теме пишут. Вот я думаю, как авиация там вполне. Так вот, там было довольно забавно. Они, значит, делали как раз именно личный кабинет, там, каталог тарифов и так далее для мегафоновских вот этих ребят, которые просто стоят за столом и, соответственно, раздают людям эти все штуки. И прямо при мне была классная ситуация там, я не знаю, может, Миша Рыжиков, ты его знаешь или нет, из Питера, очень такой тоже чувак интересный и достаточно известный, там в кругах определённых. А значит, он возглавил одну из команд. И первое, что он сделал, то есть команда там всё, значит, по скраму, всё, как полагается, у них там микросервисом, всёвсвсёвсвсё. Он первое, что сделал, ребят, мы едем, собственно, в поле. Он собрал свою команду, и они просто тупо поехали вот в один из офисов, в котором, соответственно, работают с B2B клиентами. И они несколько дней там сидели, и они просто вернулись с другими людьми. Но, естественно, он это целенаправленно делал. Он туда программистов всех своих заслал. И это очень сильно сработало в плане понимания всего остального. Но вот когда ты говоришь про DD, это как будто здесь вообще отсутствует как класс и потому что это считается ортогональным или это неважным или как. Просто интересно. Мне, кстати, раньше эта мысль в голову не приходила. Вот просто сейчас ты говорил и я подумал: "Хм, а почему здесь нет реальных пользователей?" Ну, под стехолдером можно подразумевать кого угодно, да? То есть это, ну, переводя на русский, это заинтересованное лицо, да? То есть в данном случае заинтересованное лицо, да, были люди настойке. Вот, э, поэтому он как к ним и поехал, да, то есть здесь можно сказать, что он точно также пошёл к стехлордам задавать вопросы. Я в моём примере пошёл к трейдеру, да, который там пользовался этим стаканом, да, он пошёл к конечным потребителям. Вот это плюс-минус одно и то же, да, во многих компаниях так делает. Вот я вот, допустим, работал в Сбермаркете, и там каждый условно разработчик идёт в так называемые поля, да? То есть ты приходишь на работу, тебя отправляют на склад курьером, там кем угодно, да? Там даже SEO работал курьером, чтобы лучше понимать свой бизнес. Ты про Илью? Да, он опаздывал на заказы, его там материли как бы за то, что он опоздал на заказ. Он извинялся, отдавал, шёл, да? То есть каждый человек, который работал в продуктовой компании, он должен был её прочувствовать через реально клиентский опыт. Вот. И здесь, э, эти люди, возможно, они не знают про DDD, да, они не знают, что это такое. Но часто мы делаем что-то, да, не называя конкретных слов, да, но делаем, потому что посчитаем, что это классно. В DDD это называется исследование предметной области, да, понимание предметной области. В примере с Мегафоном, да, в примере с бермаркетом, люди занимались примерно этом, да, но они не знали, что такое DDD, но вот двигались в эту сторону. Если потом всё собранное знание ещё наложить на знание DDD и постараться это разложить в компании, то это будет просто ещё большая польза. Вот поэтому подходы они очень близки. Плюс-минус цель достигается одна и та же, да, цель в конечном итоге еда. Я единственное только всё-таки хотел сказать, что вот когда ты говоришь про стейкхолдеров, там как раз именно в этом фишка. Вот если в экстремальном программировании чётко, ну, почитать, что они говорят, там прямо идёт акцент на то, что, ребят, мы ни в коем случае не про стейкхолдеров заказчиков. То есть речь идёт про пользователей системы, то есть фишка этого пункта, что заказчик стейкхолдер и пользовательстйхолдер - это не равенство между ними. То есть вы типа обязаны, ну, скажем так, это рекомендация, да, что экстремальное программирование - это идём именно всегда к пользователю. Ну, естественно, помимо заказчика, да, понятно. Ну, смотри, интересный кейс, да, вот я уже не раз говорил слово аваншторминг, да, это вот как раз, э, ну, расскажу, что это вообще такое. И, соответственно, методика некоторая над над нас надслоение над DDD, да, то есть DD - это просто концепция, да, то её нельзя потрогать, она вот просто вот как философии. А, Morминг - это конкретная методология, как нам условно происследовать какую-то предметную область визуально, да, то есть построить какую-то схемку, разрисовать её, пообщаться с стекхолдерами, сейчас мы про них поговорим, и собрать с них информацию к себе. понять, какая там доменная модель, какие субдомена, какие баунко контексты, и уже потом пойти в разработку. Осознанно пойти в разработку. Не просто пальце в небо, я решил такой сервис сделать, а осознанно пойти. Вот. И вот когда мы говорим про стехолдеров, да, возникает вопрос: а кого на этот аванрминг позвать? Да. Вот я расскажу, кого мы на него звали. Мы звали на него как midleменеджмент, да, то есть там юнит литы и выше продуктовый продукт лит выше. Звали туда сотрудника кол-центра, звали туда курьера. Да, то есть чувствуешь, то есть можно позвать кого угодно, и там как раз такая рекомендация. Вам не важна роля, неважно, кто какая человека роль. Главное, чтобы он просто шарил в этом процессе. Если он шарит и может тебе как бы объяснить, как это работает. Либо в реальности, либо методологически. Лучше, если на этом шторими есть человек, который знает, как это методологически работает и как это реально работает. Они сталкиваются лбами, обсуждают, мы получаем реальность. И потом мы идём программировать реальность, а не наши догадки, как нам казалось, что должно и быть именно так. Вот поэтому, когда я говорю стейкхолдер, я имею в виду любого человека, не разработчика, не аналитика, того, кто так или иначе является заинтересованным лицом в построении системы, которую мы строим. Вот это может быть как сотрудник Allset, так и какой-то топ-менеджер. Угу. А, о'кей. Я прямо, знаешь, почувствовал, э, как бы вот в процессе, что, видимо, сегодня я в основном буду выступать в качестве адвоката дьявола, потому что нужно как бы тезисы эти разбирать. Почему? Объясню сразу, чтобы понятно было тем, кто нас смотрит, ребят. Просто вот эти вот тезисы, что это поддержимо, это нет. Естественно, я их тоже много слушаю, но я понимаю, что для людей это выглядит, понимаешь, как пустой звук. Они такие: "О'кей, а почему вдруг?" И я, соответственно, сейчас тебя немножко помучаю и подушню, чтобы мы с тобой вот прямо дошли до ядра, типа, а что конкретно вот что было бы, если бы я не знал, что будет, если я знал. А вот, а знаешь, я оче подумал, пока ты говорил, ты вот этот процесс, описывая, подразумевал неявно, по крайней мере, это так следует из того, что описываешь, что это какой-то существующий процесс, который мы дорабатываем. То есть это прямо что-то серьёзное. У тебя уже есть курьер, у тебя уже работающий бизнес, у тебя вся фигня. Допустим, прямо сейчас кто-то такой решает: "О, я сейчас делаю и аватаров, который что-нибудь там". И таких сервисов в жизни не существовало. Это абсолютно новая штука. Никто никогда с ней, никто не понимает, как она вообще будет работать, взлетит или не взлетит. Ну такой аля классический стартап, который вот прямо вообще мы не понимаем. У нас никого нет. Нет курьер, у нас никого нет. У нас даже пользователи там ещё не понимают, надо им это или нет. Угу. Хм. У нас получается просто, что часть процессов выпадает, мы как-то по-другому начинаем действовать. Или где вот в этой части соединения или типа здесь это просто не подходит и тут мы этим не занимаемся? Ну у меня всегда позиция, что в стартапе нужно думать о зарабатывании денег, а не о технологиях, концепциях. Это первый ответ сразу же, да? То есть это, ну, номер один, о чём надо думать, потому что частом бывает люди там в стартап Кубернетас тащат микросервис, а потом деньги кончаются, они всё это барахло выкидывают. Вот поэтому фокус на деньгах, если мы говорим про стартапы и неважно, применяешь ты там ДДД, не применяешь, это второстепенно на данной стадии. Вот. Но в то же время, да, всё равно уже у нас возникнет потребность, ну, что-то создать, да, какую-то, ну, систему, да, и у этой системы будут какие-то сущности, да, эти аватары, они будут делать какие-то действия, да, и почему бы, к примеру, если я как разработчик обладаю там знаниями тд, почему мне не выделить сущность аватар, почему не выделить действия, что он там может делать, что он может там, допустим, запускаться, останавливаться, начать диалог, закончить диалог, что-то там ещё сделать. Почему бы не использовать сразу это, да, если этим знания обладаю? Если я не буду этим зданием обладать ДД, ну тоже я сделаю аватара. Вопрос просто в том, что будет с этой системой через 2-3 года. На практики, да, вот все, кто вы сейчас вот работает, видит всякие LEC монолиты, где там всё как курица лапой написано, это вот плод того, что люди как бы не знали скажем, каких-то подходов, да, как я уже говорил, что ДД - это просто оп на стероидах. Вот поэтому если вы видите кейсы на три экрана и мучитесь вот это это вот результат работы людей, которые не знают ничего про ДД. Угу. Вот и с этим стартапом примерно тоже, да? То есть его либо как бы он будет превратиться в такой же LEC монолит, да, спустя 2-3 года, либо его кто-то там отрефачит в какое-то нормальное состояние. Вот я даже видел кейсы, да, когда люди запускали микросервисы год назад, да, то есть люди в начале года его запустили, а в конце года они уже бегали по компании, говорили, что у них LEGOC код, им нужно его полностью переписывать. Вот. И тут явно проблема была не в монолите, не в микросервисах, а в способности строить внутреню архитектуру этого приложения. Я хочу одну вещь сказать по поводу вот микросервиса. А, смотри, тебе не кажется, что какой-то есть какой-то парадокс? Если у тебя это микросервис, он, скорее всего, его размер настолько маленький, что как бы Галима ты его не написал, его чуть ли нешкой можно с нуля перегенерить и не париться. То есть что это за микросервис, которого есть архитектура и он устарел? Я понимаю, архитектура между ними, но архитектура внутри микросервиса аля из серии минимально там, не знаю, там сущности насоздавал и какую-то логику написал. То есть, чтобы выходить на уровень, что тебе надо ещё тут слишком особо думать, у тебя там контексты появляются и вообще типа сложно. Неужели это разве микросервис? Ну вот вот вот к этому как раз мир и пришёл года полтора-два назад с пониманием, что микросрвис - это не просто маленькое приложение, которое там можно переписать яишко за один день, а это просто более, скажем так, фундаментальная вещь. Вот. То есть мы опять вернулись к сервисноориентированной архитектуре и просто забыли убрать слово микро слова сервис. Да. Ну да. Если говорить про сам подход микроссервис, сам автор говорит, что он слово микро зря эту концепцию добавил, потому что весь мир его понял. Вот примерно вот сказано, да, что это типа одна функция в одном сервисе функци у нас в продукции там не 200 функций и тогда сидит команда человек поддерживают 200 микросервисов. И они просто только занимаются тем, что они чинят пожары, там их обновляют и так далее, тратят, ну, своё время и фокус на инфраструктурные задачи, а не на продуктовые. Ну, и в итоге компания просто начинает угасать со временем. Вот поэтому, ну, на сегодняшний день, да, это микроссервис - это какой-то либо баound контекст, либо какая-то его часть. Вот, то есть сервис, который решает какую-то конкретную проблему, да? То есть он не должен решать проблему функцию, он должен решать конкретно проблему. Допустим, если мы говорим про Market - это корзина. Вот хороший пример Micros, да, но там не одна функция, там много функций, да, там и адрес могу добавить, и товар могу добавить, и убрать его могу, и у меня там этот сервис может в другой обратиться, там, допустим, комиссию какую-то пересчитать. Поэтому нет, Microsрвис - это не то, что можно перегнить за один день или переписать за 2 недели. все вот эти утверждения там, что не больше там 2.000 строкода, что может пристать через 2 недели, это всё, это всё сказки. Вот это, ну, скажем так, просто сама идея провалилась, да, а мы как бы многие продолжают, ну, поскольку это всегда инерцию имеет, да, люди до сих пор вот живут часто в этом восприятии и словом этим называть. Не, идея не провалилась. Идея не провалилась. Если мы откроем любую книжку про микросервиса, да, в первой же главе будет написано про баун контекста. А её просто все её всё просто все пролистали. такие: "Ага, ну давайте про GPC почитаем". Вот разработчику техническому всегда интересно там кавка GPC, там вызовы входящие сходящие, да? А вот первая глава, в которой написана про баунт контекст, про философию, да, как это вообще вот как границы определить, они таки всё ж понятно. Мы сейчас мы сейчас в этот уровень с тобой, да, перейдём. Я просто, наверное, хотел подчеркнуть, что сервисы не сегодня появились и не вчера. И до того, как вообще заговорили об этом слове, ну, любой вменяемый разработчик, кто писал там ещё 10-20 лет назад, прекрасно понимает, что есть сервисы, у тебя сервисная ориентированная архитектура. То есть мы как будто бы вернулись к этому. Ну, как пример, вот для меня, например, если у тебя веб-проект, у тебя, как правило, самая очевидная вещь, которая просится на выезд, ну, то есть вот выделить, а это биллинг. Потому что биллинг, как правило, это некая самостоятельная единица. Она довольно очевидна вот отдельно от твоего приложения, да, у тебя каким-то способом поступают деньги, а для приложения просто, ну там ну фактически открываются доступы. А то, как это сделано, неважно. То есть биллинг - это всегда некая отдельная штука. Ну вот в типовых, скажем так, веб-проектах. Поэтому в этом смысле появление новых книжек, слова микросервиса, они просто не нужны. Это просто естественное желание и понимание и бизнеса, и разработчика. Ну да. Ну у тебя возникает вопрос, это билинг сделать из 200 сресов или там из одного? Да. И вот ответ на вопрос: как правильно? Вот. И вот вопрос не на поверхности. Вот если сравнивать, допустим, микросервис и сервисну архитектуру, да, то есть с точки зрения границ на сегодняшний момент мы плюс-минус, ну, одинаково, ну, смотрим, а микросервисы от SUA отличаются, ну, некоторыми конкретными паттернами, да, если там в SUA было о'кей ходить в одну базу, то из двух сервисов микросервисов, это просто табу. Тех делать не надо, прямо это жёсткий антипаттерн. Вот есть там ещё много нюансов, чего мы там должны делать и не должны делать. Вот поэтому там отличия всё же есть. А вот с точки декомпозиции, да, когда мы говорим там про СУА, про микросерсы, про монолиты, в принципе, на мой взгляд, ничего не поменялось. Просто в какой-то момент времени люди, ну, ошибались, приходили к правильному решению, потом опять ошибались, да. Вот мы сейчас коснулись размера, да, микросервиса, сейчас разобрались, какой он всё-таки должно быть. А основа основ, да, про деление на модули, да, оно было заложено ещё там 100 лет, ну не 100 лет, а условно там в девяностые годы, да, в девяностые годы, да, тогда когда был появлялся DDD, когда были Мартин Фаулер написал свою книжку, да, про построение корпоративных, как она там называлась, корпоративных архитектуры кажтех приложений, да, её потом переименовали в шаблоны, да, вот это всё было давно известно, да, просто в какой-то момент, ну, не все там, скажем, это применяли, Ну, деление на модуль, оно было, есть, остаётся и оно пока не меняется. Я единственное только, а знаешь, вот у меня, наверное, другое к этому немножко отношение, потому что ты говоришь вот типа в сервисно ориентированной архитектуре так, а в микросервисах так. А, честно говоря, это это же не научные законы выраженные, ну, всё вот фундаментальные, да? То есть когда, например, я про это говорю, я вообще не воспринимаю так, что вот, ой, мы тут микросервисы, а вот тут мы это, а тут это. То есть, например, я прекрасно понимаю, что, например, мы какие-то делаем сервисы и для нас, например, очевидно просто из опыта, из какого-то понимания, что в одну базу ходить нельзя. То есть мы, в принципе, никогда так не писали сервисы. И при этом, если меня спросят, я никогда, никогда в жизни никому не скажу, что мы пилим микросервисы и также никому не скажу, что я следую архитектуре. Я просто инженер, и я следую пониманию тому, как как делать правильно. Поэтому, мне кажется, вот эта вот штука, она тоже создаёт, ну, знаешь, такой слой вот этого вот срача какого-то ненужного. Так, а вот здесь этот написал так, а этот написал так, как будто жизни за рамками этого написал нет. Как ты к этому относишься? Ну так-то да. Вот. А ну я видел много кейсов, да, где люди так или иначе ходили в одно баз данных, потому что почему нет? Потому что это быстрое, удобно и задачу сделают и не через неделю, а завтра. Вот. И их похвалят. Вот поэтому такие кейсы есть, да? То есть не нужно говорить, что их нету. Вот. И, э, в целом, если мы прочитаем про все концепции, да, там, что экстремальное программирование, что DD, что микросервисы, что там, ээ, как писать код там нашарp или гонгеля Джаве, да, можешь просто написать: "Ребята, делайте просто хорошо, как хорошие инженеры, и книжка закончилась". Вот. Но там люди пишут: "Да, делайте так". И потом потому что потому и вот это потому, что потому это как раз обоснование, почему делать так. Вот. И когда мы говорим про там то, что в одну базу данных ходить нельзя, да, можно, возьми, сходи, почему нет? Но есть почему, какими проблемами это проведёт. Вот для кого-то, допустим, разработчик, который только сегодня зашёл, допустим, построение распилённых систем, для него не очевидно, почему он в сосидний сервис может обращаться, а в соседнюю базу данных не может обращаться. И вот ему нужно какое-то правило, да, куда он зайдёт, посмотрит, и там будет написано так не делай и обоснование, почему не делай. Вот поэтому, на мой взгляд, это очень удобно. Свод каких-то правил с обоснованиями. Если бы там не было обоснования, просто не делай, потому что не надо. Это бы было плохо. Вот. А так там всё написано. Я немножко про другое, знаешь, именно про что. Это же всё просто стечение обстоятельств. То есть кто-то выпускает книжку и появляется типа как концепция микросервиса. То есть по какой-то причине мир решил, что сервисноориентированная архитектура - это некая штука, которая не меняется. Вот просто ты же сам сказал, типа там можно это делать, а кто сказал, что это зафиксированная штука, которая не меняется со временем? Типа мы же как инженеры растём. У нас не для каждой штуки придуманы такие слова, между прочим. То есть почему мы считаем, что в современном мире в Суа можно ходить в разные сервисы? То есть это кто-то просто в книжке написал. Я сильно сомневаюсь, что есть фундаментальная книга научная, где вот написано, что надо так. То есть я имею в виду, сама концепция развивается. Тебе для этого не надо придумывать новое слово. Я к тому, что вот этот уровень он вышел, видишь, такой как раз вот как ты про политику говорил до этого, на уровень такого маркетинга. Кто слово захватил, его используют. И теперь говорят: "Вот у нас в скраме так, а вот здесь не так". А вот это только в скраме есть. А если у тебя этого нет, это не скрам. Ну, знаешь, вот типа когда вот эти вещи обсуждать начинают, вот мне кажется, это что-то из этой же серии. Ну, я, честно говоря, не слежу последнее время за SUА, как бы, да, то есть условно она была, побыла, потом вот перешли мы на микросервис и в целом про тему SU терминология поменялась, да, больше не касался, да, но на те времена, вот насколько я литературу изучал, там типа вполне было о'кей, да, вот сходить в базу данных с двух разных сервисов. Вот как там сегодня, я не знаю, возможно, там что-то поменялось, но неизвестно. Короче, я просто хотел подвести вот как бы черту здесь, что SUA - это не набор стандартов, которые типа придумали когда-то и вот типа всё оно есть и дальше оно устарело. Это просто на самом деле всё-таки обычно название, что, ну, мы в принципе на сервисы делим, а то, как мы это делим, естественно, эволюционирует со временем. Вот. Но с точки зрения мира, естественно, появляются типа аля новые аббревиатуры, новые понятия и как будто бы типа что-то новое. Но ты такой понимаешь, что это то же самое просто, ну, бестпрактиксы обновились. О'кей. Ну да, ну всё, там была entтерпрайз Бass в микросервисах. Если воснёшь Enterprise Bass, тебя там все как бы захейтят. Ну это если ты эти книжки читаешь, да? Если ты читаешь книжки по ирлангу, то у тебя там другие вещи написаны. Поэтому тут очень, говорю, эта история, она такая супер, она вот как дд ДД, то же самое, да? То есть, например, если мы берём в среднем по рынку, я просто готов поспорить, что у тебя процент людей, который про это говорит, используют и вообще спрашивают на сабесах среди дотнетчиков, например, не просто на 5% выше, а прямо типа сильно выше. Ну, на собеседование гошников, я думаю, ты этого не встретишь. И этот разброс, он как бы тоже показательный. Ну, то есть типа если бы у тебя была некая универсальная концепция, она мы знаем, что это, в общем-то, универсальная концепция, но всё же мм оно сильно прилипает к группам. И эти группы иногда делятся по языкам, а иногда ещё по каким-то срезам. Ну, это не с языками, на самом деле, связано. Это связано просто с тем, что на языках реализовывают, да? То есть мы возьмём пример C#P, да, то C#P всю жизнь на нём имплементировали бкофисные enterprise-системы. А на Гуленге как бы изначально имплементировали какие-то нагружены системы, да, фронтовые. Вот. Но на сегодняшний день на Гулнге делают и кффис на entтерпрайз система, поэтому я вполне уверен, что это просто вопрос времени, да, то есть когда это будут спрашивать на сабесах. Вот поэтому тут не не от языка зависит, а именно от какие проблемы на языке решаются. И тогда уже люди, когда на нём решают проблему и понимают, что решать её простым, примитивным способом, там, крут приложениями уже как бы не о'кей, они думают: "А есть ли какая-нибудь классная концепция, которая нам решит эту проблему?" Да. И вот они идут в ДДД. Вот. Если гошник там делает, ну, джесоны там отправляет куда-то, да, и наком это ДД. Вот сегодня он не нужно, а завтра он начнёт делать какой-нибудь там корзину, к примеру, ему ДДД понадобится. Вот это просто вопрос предметной области. О'кей, поехали тогда дальше. А, немножко назад откатимся к философии. Тут я, наверное, такую вещь добавлю. Просто ты много говоришь про сущности, про разбиение. Мы про баундут контекст и вот про все эти вещи чуть позже поговорим. Есть ещё более фундаментальная вещь, да, связанная с единым языком. Просто для меня всегда как бы фундаментально, вот, потому что когда мы на конференциях встречались, спорили, использовали, для меня фундаментально ДД в первую очередь вот как бы вещь, которую я абсолютно поддерживаю и она как бы довольно нативная, то есть типа это не значит, что это прерогатив ДД, да? То есть типа и без ДД тоже есть прекрасно. Это единый язык и вообще то, что ты с бизнесом вырабатываешь некую общую терминологию и понятийный аппарат. И примеров здесь можно привести миллион. Ты, например, автоматизируешь какую-то фигню, а у тебя же по сути это не значит, что там есть аналитики, ещё кто-то, да? Это просто может компания быть, там просто сидят ребята и что-то делают, и ты, ну, вот, например, для для строителей мы делали, у них там, значит, отдел 60 человек, которые только бумажки перекладывают, и это довольно сложно. И вот, естественно, у них никого нет, они просто вот делают это в существующих системах. Вот они нас приглашают и говорят: "Давайте, ребята, вместе с вами всё это автоматизируем". И когда он говорит: "Ты понимаешь, что он просто тупо выразить словами это не может". Вот у него там в какой-то системе есть какой-то выпадающий список и там плюсик добавить что-то. Естественно, он же не мыслит понятиями: "О, у меня тут связь, у меня тут сущности и всё что-то". Он просто такой: "Ну, у меня тут документ, я прикрепил". Иногда он это выражает настолько как бы сложно и непонятно, что он сам не может это объяснить другим. То есть это такой совершенно другой какой-то птичий язык, который очень-очень недертерминированный. И ты понимаешь, что вот где я это вижу, как это применяется. Эван же сам про это писал, да? Что, ребята, главная задача ДД - это как девопс, коллаборация. У вас бизнес разговаривается с разработчиками, и разработчики учат, с одной стороны бизнес, но бизнес с другой стороны тоже немножко адаптируется. И я это использовал как, то есть мы, например, вот последний кейс. В прошлом году мы делали систему для студентов. У нас колледж, а там подают документы. Как ты понимаешь, подача документов серьёзный процесс. У тебя там миллиарды зависимостей, скидки всякие, маткапиталы, ты, может быть, военнообязаный и так далее. И там вот очень сложные сценарии, которые никто даже до конца не понимает. И вот мы сидели просто днями целыми вот типа так, о'кей, выписываем, о'кей, что в этом. Иногда они такие пытаются как-то это объяснить, и ты им говоришь: "О, ребята, так это же просто, например, там вот такая-то фигня". Они такие: "О, мы на это ни так не смотрели никогда". Я говорю: "Давайте договоримся вот о таком понятии, будем это вот таким образом называть и понимать, что оно вот так работает". При том, что даже я владелец как бы этого бизнеса. То есть я как бы владелец и одновременно программирую, понимаешь? Это, ну, не каждый день такое увидишь. Я вижу сопротивление с той стороны. То есть они такие: "Мы привыкли к таким-то понятиям, но мне проще. мы всё равно как бы добиваемся того, что было всё вместе. Но это действительно занимало много времени. И я рад как бы тому, что мы это проделали. Это помогло нам. А это, чтобы ты понимал, это продажники в первую очередь. Сам понимаешь, им не то чтобы горит с нами это общаться, им эта система нужна, но они типа из серии сделайте сами, мы к вам лезть не хотим. И почему я долго про всё это говорю? Вот для меня вот это самая главная история, которая как бы потом уже приводит к коду. И уже вот то, что ты говоришь про код, как там оп, не оп, я, честно говоря, считаю очень сильно вторичным, потому что бывает сильно по-разному. Но вот эта часть как бы главная. А просто когда ты говорил, ты её так сильно, то есть ты как бы про неё говорил, но вот эту часть не выделял. Ты так же на это смотришь или не? Ну да. В моей истории, где мы пошли к трейдеру, примерно так всё это было, да? То есть он нам также на пальцах объяснял, и мы его не понимали, а он нам всё равно объяснял. Вот. И здесь то же самое. То есть, да, нужно, естественно, стараться, скажем так, как кодировать, да, и коммуницировать теми терминами, да, которые говорят бизнес. Я здесь, наверное, не совсем согласен, что нужно бизнесу навязывать наши термины, да, скорее всего, они лучше нас знают, какие там термины могут быть. Я не про подмену, я скорее про то, что они иногда их не могут нормально выразить. То есть у них, например, есть связь один ко многим. Ну, например, у одного студента может быть много паспортов там. Да, да, да. Вот в этом как раз и есть фишка, да, человека, который с архитектурным бэкграундом, да, и бэкграундом хотя бы в оп, да, что когда ему говорят: "Смотри, я нажимаю на экран, у меня всплывает другой экран". Значит, там какая-то такая связь, да, у человека, который, ну, не понимает в архитектуре и в разработке, да, он мыслит экранами в лучшем случае, да, и поэтому вот эта вот концепция экранов, ну, от неё как бы, скажем так, можно на неё ориентироваться, да, но зачастую она, ну, не всегда соответствует тому, как у нас должны взаимодействовать сущности на бэкэнде. Вот. А, поэтому, да, зачастую вот люди, к которым мы идём, они могут вот выражать свои мысли таким образом, но наш навык и наш, скажем так, скилл должен заключаться в том, чтобы пытаться понять его и у себя в голове сложить ту модель, которая должна сложиться, показать ему, и он скажет: "Ну да, точно, вот так оно должно быть". То есть задавать уточняющие вопросы: "Да, а вот это с этим связано?" Нет, с этим не связано. А вот это является подчинённым сущностью-то в другую сущность? Ну, скорее да или нет? Вот. и вы постараться понять, да, что у нас там товар в корзине или корзину в товаре. Ну вот, условно, что-то в этом роде, да, то есть выделять, потому что как мы потом дизайнер всё это сложит на экраны, он может это как угодно сложить, да, мы можем вообще хоть вообще всю нашу доменную модели, всю нашу систему сложить на один экран, но это не значит, что мы должны делать всё вот на бэкэнде точно так же всё тесно связано. Вот с точки зрения единого ЗК, да, вот был кейс, да, из жизни, когда бизнес говорил одним образом, разработчики с бизнесом не разговаривали, они сделали, опираясь на свои какие-то понятийные вещи. И потом возникла проблема перевода, да? То есть бизнес говорил, что клиент отправляет заявку, а у разработчиков в коде была название анкета. Вот. И потом, когда только приходило совещание, говорил: "Ну, мы тут анкету создали, все такие: "Какую анкету? Никто не понимал, что за анкета, короче. А когда бизнес приходил и говорил им, что нужно в заявке пару полей добавить, они говорят: "Что заявка? У нас анкета". Вот. И вот на вот эту мискоммуникацию тоже уходила куча времени. Это просто всех бесило раздражало, пока эту анкету не переменали в заявку. Вот поэтому я всё-таки, да, сторонник того, что вот если бизнес говорит терминами, стараться к ним прислушиваться. Но тут нужно тоже смотреть, с кем ты разговариваешь. Иногда человек вот который, не знаю, в документы форму отправляет, это, возможно, человек, который, ну, вообще не понимает, что он делает, он их просто отправляет, да? А где-то за ним стоит его руководитель или какой-то методолог, который эту систему придумал в этой конторе. И вот нужно с ним поговорить, как он это задумывал и почему он так это задумывал. Вот. Поэтому здесь тоже нужно найти правильного человека, с кем разговаривать. Вот иногда есть люди, которые что-то делают, но они на самом деле не являются экспертами, они просто конкретно исполнители. Вот такое тоже есть. У меня у меня, видишь, такая особая ситуация. В моей ситуации я и есть бизнес, знаешь, как в этот лысый. То есть это же моя история. Другой вопрос, что а у продавцов своя терминология, поэтому, например, нам их надо было фиксить, потому что они местами не зная, то есть они же просто продавцы, они попадают в образовательный процесс, и у тебя в образовании есть свои штуки, но они как бы используют какие-то свои. То есть всегда это очень такая сложная история. Там, например, заявка, которую подают там специально мы исследовали там за рубежом, оказывается, называется понятием adдмишionн. Мы такие: "О, всё там, значит, надо его использовать". Ну и так далее. Потому что даже бизнес - это не история про то, что ты знаешь всё, чем ты занимаешься. Это всегда очень сложная история, да? Потому что бизнес - это не всегда ты такой: "Я всю жизнь этим занимался". И вот я, значит, запускаю тут бизнес, и я эксперт максимально в этой терминологии. Вообще и так не работает. Вот поэтому и ошибок бывает, и всего на свете. У меня есть прямо пара примеров на эту тему. Я хотел бы вот тут немножко даже с тобой остановиться, потому что я думаю, что многие люди недооценивают, насколько терминологическая вот эта проблема является огромной проблемой. Потому что вот всё, что ты сейчас тоже рассказывал, когда одни говорят одно, вторые второе постоянно в тикетах, при разговорах, при взаимодействии с клиентом, когда они ставят какие-то требования или изменения, потери здесь могут такие огромные быть. Я где-то слышал про исследование, что типа 40, ну, понятно, что это странно понять, что это означает, но типа 40% времени уходит на потере, короче, коммуникации, на недопонимании, связанном с тем, что не выработан единая терминологическая база. Значит, пару примеров. Когда я в этом Петрсервисе был, там я был в составе отдельного отряда, значит, Agile тренеров. Я отвечал именно за инженерию, они больше за процессную составляющую. Мы, значит, ходили, там больше семидесяти команд только внутри было. Мы, значит, подключались к командам и занимались её, значит, пересборкой, да, чтобы там и по процессам, и по инженерии всё было хорошо. И, например, мы работали с одной командой, ребята, которые отвечали за процессы, тренера, они устраивали им тренинг. Знаешь, какого плана? У них постоянно были срачи, и они не могли постоянно договориться, потому что они использовали все слова модуль в качестве, ну, а там как бы с командой чек 15, там тестировщики, а, менеджеры, ну, в общем, все подряд, короче, они такие сами там управляют каким-то набором сервисов. У них слово модуль обозначало семь разных вещей. Был прямо тренинг, на котором я скорее просто как наблюдатель был, в рамках которого каждый говорил, что означает слово модуль, почему они его так используют, и они пытались договориться о том, как они переименуют, всё пере соберут, чтобы в конечном итоге никогда больше не надо было делать уточнений на эту тему. Этот тренинг занял 2 часа, чтобы ты понял. Вот только эта история. То есть насколько это серьёзно, насколько это болезненно. И это было только в рамках одной команды. Они же ещё и с другими людьми взаимодействуют, да? А у нас, например, на Хекслите есть очень прикольный пример, который нам до сих пор стреляет и и мы всё время в него упираемся, и уже ничего с особо с этим не сделать. У нас изначально как бы курс на Хекслите - это была очень маленькая единица. То есть на самом деле сам по себе курс он прямо микроскопический. Например, курс по массивам, но в реальности всё вместе составляет собой программу обучения. И мы так и писали когда-то на сайте программы обучения. Но здесь есть маленький нюансик вот к вопросу о том, что такое бизнес. У тебя бизнес определяется не только тем, как я решил, как владелец бизнеса. У тебя есть спрос. И если люди считают, что программа обучения -ние - это очень странное понятие, правильное понятие - это курс, ты должен писать слово курс. И ты понимаешь, там, где у нас были программы обучения, появилось слово курс. И у нас курсом как бы внутри мы знаем, что у нас есть программа обучения и внутри есть понятие курс маленькая единица, но снаружи у тебя как бы курсом называется и то, и другое. То есть и понимаешь, и когда тебе кто-то с той стороны, либо зака, в смысле, клиент, либо кто-то со стороны бизнеса, в том числе я сам, я как бы сам и с разработки, и со стороны бизнеса, я сам с собой в голове, знаешь, так получается спорю. Ты говоришь слово курс, тебя всё время уточняют, о каком курсе идёт речь. И мы придумали: "Так, давайте эти курсы называть внутренними, давайте эти курсы называть, а, не, ну, там, чуть неполноценными там, и так далее". Короче, это супер серьёзная проблема, которую надо решать. И, по-моему, в книжке даже, да, про это писалось. Если, ребят, у вас сущность называется не так в коде, ну, переименуйте её или хотя бы как-то вот сделайте так, чтобы вы её называли по-другому. Вот этот мапнга в голове быть не должно. Ну да, всё так вот. Э, и, кстати, вот как раз, когда мы говорили про курс, да, программу обучения, да, и это начал задумываться, что во что входит, да, что чем является, это вот как раз есть мыслительный процесс, да, вот когда мы говорим про построение доменной модели там в стиле DDD. Вот, то есть мы такие вопросы именно должны задавать. Вот. Но что касается языка общего, ну вот честно хочу сказать, что я крайне редко, вот если говорить про DDD, то многие концепции применяется, да, но вот именно вот формирование вот этого идимого языка, ну вот я практически нигде не встречал. То есть э очень вот эту концепцию, её, на мой взгляд, она самая сложная, самая, скажем так, неочевидно, выгодная для компании. Вот. и так, чтобы кто-то его сформировал, да, вот на каком-то там уровне, да, и чтобы там на уровне всей компании применялось, кто-то за этим прямо следил чётко. Ну вот, честно говоря, такого не видел. Вот. Э, поэтому вот субдомены, баун контексты, да, деление на модули, да, тактический дад, да, вот, а вот единый язык, вот он почему-то как-то не приживается. Вот, э, крайне редко может что такое, знаешь, это выглядит так, что скорее эта проблема настолько, мм, ну, поверхностная, грубо говоря, вот как я привёл пример, да, когда все тупо начали путаться и у тебя естественное желание возникает: "Давайте это пофиксим, и тебе не нужно где-то, чтобы это было выписано". Да? То есть вы просто Да, да, то есть на уровне одной команды это, конечно, да, решается, да? То есть, когда мы приходим на какую-то встречу, да, на обсуждение какого-то проекта и там начинаем там тот же AVшторминг, да, который постоянно называю, там есть такое понятие термин, да, когда мы начинаем это всё расписывать и встречаем два термина, которые как бы нам кажется, что про одно и то же, но почему-то один человек написал, второй написал аккаунт, а третий написал клиент. И это всё одно и то же или нет? Четвёртый лид написал. И вот мы начинаем мапиться и приходим к одному конкретному термину, который будем использовать. Мы всё это переправляем на этой схеме, заводим термин, даём определение на русском, на английском и в схеме это всё фиксируем. Вот. То есть когда мы решаем какую-то конкретную задачу, да, проводим исследование предметной области, а, да, этот единый язык формируется и для конкретной локальной задачи он типа работает. Но так, что потом это, если мы это приняли, то это мы занесли в какой-то там, не знаю, словарь всей компании. Все в компании начали это использовать. Вот на и кто-то это контролил, что все это используют. Вот такого ни разу не встречал, чтобы тот вот на таком серьёзном уровне это продвигал. Вот. А локально? Да. Дада. Да. Ну иногда бывает такое, что ты там всем пишешь там типа: "Ребята, вот эту штуку назовам так". Но у нас такое точно бывает иногда, потому что это создаёт большие проблемы. Это видишь зависит ещё от уровня бизнеса. Вот ты говоришь промежуточноные звень. У меня компания относительно небольшая, и поэтому у тебя любой маркетолог может пойти напрямую там в разработку. И когда у тебя коммуникации довольно много прямой, то это, конечно, проблемой становится, потому что они там на своём птичьем разговаривают, у тебя нет возможности типа: "Ребята, давайте созвонимся, сядем". Ну, это могут быть быстрые какие-то конкретные задачи. И просто для того, чтобы снизить вот это вот в тикетах из серии, ребят, ну, давайте поясняйте, что вы тут хотели сказать. Такой, знаешь, микро такие тренинги из серии. Собрали всех маркетологов, сказали: "Разработке нужно говорить вот это". Они такие: "Есть, ну, потому что, скорее всего, чаще всего именно так происходит, потому что они, как правило, ставят задачу. И, ну, нужно, чтобы всё-таки они немножко понимали, что они ставят, иначе просто невозможно работать. То есть тебе нужна прослойка. Вот. А в нашем случае мы позволяем себе без неё работать. Ну, с другой стороны, даже если этот словар не формировать, а просто вот сделать простое правило, да, допустим, там минимальный бэкграунд вдиде, допустим, у разработчика есть, он уже, когда пойдёт на совещание с с маркетологами предста бизнеса, он уже будет априори стараться из них вот эти термины как бы вытаскивать. и он точно будет стараться их в коде их применять, а не какие-то свои термины. Вот. И в целом, если у нас даже такое базовое простое понимание, да, на уровне разработчиков будет, и даже не будет какого-то формального правила, что нужно это единозго формировать, они просто это на уровне вот понимания будут каждая команда делать, то он таким образом и сформируется много локальных языков. Ну, собственно, как Эванс в итоге сказал, что нет никакого единого языка, на самом деле есть един язык в рамках отдельного баунт контекста. Вот поэтому такое простое правило как раз это едины язык сформирует. Вот мне кажется, мы сейчас как раз у нас прошло пример половина, мы с тобой дошли до момента, много раз говорили слово баounded контекст, важная очень вещь. Сейчас мы к ней придём. Знаешь, я единственное, что хочу, давай небольшой с тобой эксперимент сделаем. У нас очень прикольная история, то, что мы с тобой оба терминологию и контекст курсов понимаем, да, потому что вот мы с этим работаем, да, и в принципе это довольно близкая ко всем людям штука с её просто обсуждать. Давай немножко поиграем в игру, попробуем. Если получится, получится, не получится, не получится. Вот берём мы разрабатываем сервис для курсов. Вот у тебя, допустим, есть как ты конкретно подходил? Вот у тебя нет курсов, ты понимаешь, что ты хочешь сделать не просто выложить его там на Ютубе, а ты хочешь прямо создать сервис, где ты будешь вот эти курсы продавать, и ты такой дд вот у тебя в какой момент оно здесь появится и как ты эти рассуждения построишь, можешь сейчас рассказать? Угу. Да, у тебя правда уже есть фора, потому что ты уже построил. Ну ладно, делай вид, что мы этого не знаем. Так же, так же лучше даже будет. Угу. Аа, ну, смотри, как я уже говорил, что для меня ДД делится на три стадии. Это философия, стратегия, тактика, да. Поэтому я бы именно пошёл бы по этому родмэпу. Во-первых, я на старте бы решил, нужно ли этот, не нужно. Если я стартапер с псяю долларами в кармане, как бы у меня есть просто зум, я просто пошёл бы в зум и стал бы делать вебинары, нике, ничего бы не запускал, взял бы коробку. А если бы дальше, да, допустим, уже нужно строить систему, да, у меня, допустим, есть люди, у меня есть личное понимание, мы всегда, ну, должны даже хоть по бизнесу, хоть как-то разрисовать customer journey map, да, то есть как этот клиент дойдёт до вот своей вишенки на торте, где он станет успешным специалистом и где он войдёт в нашу систему, да, чтобы им стать. И для бизнеса это customer journey map, да, где он разрисовывает ценность для клиента. для DDD, да, есть, наверное, странно, что я уже пятый раз говорю словошторминг, да, но есть практиками, в которой мы делаем customer journal Map, но сама нотация, она как бы разворачивается в обе стороны. Для бизнеса это как бы некое упрощённая custom Journal Map, для разработчика - это команды, агрегаты, доменные события и прочие штуки. Вот. То есть её можно считывать, э-э, ну, Технарию считывает, э, вот как я сейчас сказал, да, в технические сущности бизнес её читает, он видит перед собой бизнес-процесс. В этом и есть уникальность нотация, что обе стороны могут в ней коммуницировать, да? Потому что если я возьму какой-то BPмен, его не поймёт ни, не знаю, сотрудник кол-центра, не какой-нибудь куратор, который курсы делает, и не разработчик, который всё будет имплементировать. А здесь всё понятно. Вот поэтому я пришёл бы, собрал бы всех своих, допустим, у меня команда 10 человек, там разработчики плюс бизнес, мы бы сели бы и разрисовали бы весь этот процесс. А давай реальность всё-таки реальность. Ты 100% был один. Ну потому что 10 человек у тебя нет на это денег. У меня на это не было денег. Я уже сказал, что если я один, я не буду делать системы. Я просто куплю зум за 50 долларов. Вот интересно одному строить систему. Зачем она нужна? Давай реальный кейс. Смотри, реальный кейс. Я всё-таки сейчас буду тут немножко душнить. Значит, смотри. Первое, наверное, что хотел сказать, вот Customer Journey Map, ты просто вскользь это затронул, но мне кажется, нужно чуть больше акцента дать. Это ни в коем случае не история про юзкейсы э на сайте. Это история про человеческий путь, который вообще ни с каким сайтом не связан. Да, ведь то есть это очень-очень важно понять, потому что мне кажется, когда ты это сказал с ходу, это было непонятно, потому что выглядит так, как будто мы же про систему, а значит, вот он как там зашёл, зарегался там и прошёл курс. А ты вот как раз очень классную штуку сказал. Вообще в целом он сел и такой подумал: "О, хочу стать, допустим, специалистом по ДД или по микросервисам, вот какие у тебя курсы есть, да? Я решил и что я для этого делаю, и кем я в конце стану, как это повлияет на меня". Правильно? Мы же об этом сейчас говорим. И твоя система тут может занимать очень маленький кусочек во всей во всём этом кастомер жоонима. Ну да, но если я должен быть частью этого пути, да, потому что если им не буду, то, соответственно, он это решит проблему без меня. Вот. А им нужно, чтобы он решил проблему с помощью наших класных курсов. Вот. Ну и, соответственно, вот разрисовываем этот весь процесс, да? И вот это, когда мы его разрисовали, у нас уже решается проблема номер один. Первое, у нас решается проблема, что айтишники понимают бизнес-составляющую, они понимают, как мы вообще это всё делать будем, да. Второе, мы формируем терминологию, да, единый язык, про который мы только что говорили, да, если там есть какое-нибудь понятие, там заявка лид, что там в конце у нас может быть, там сертификат, аттестация, там ещё что-то, да? То есть тоже мы это всё как термин выносим, и у нас формируется язык, которым мы будем коммуницировать, да, тоже это выписываем на этом межторминге. Ну и дальше, да, если мы решаем это разрабатывать как монолит или как микросервис, ну давай представим, что как микросервиса, чтобы было просто ближе к реальности на сегодняшний день, да, здесь мы уже, когда имеем какой-то длинный процесс, мы вспоминаем про баунко контекст и про субдомена, да, и мы помним, что субдомена - это какой-то обособленная часть бизнеса, то есть какое-то отдельное поднаправление. Технически мне нравится очень такой термин, это что субдомен - это набор сильно связанных юзкейсов. Вот, на мой взгляд, это очень чётко олицетворяет, ээ, что такое субдомен. Вот потому что там, что как бы особенно сейчас бизнеса вот где-то в воздухе, да, а когда у меня есть набор скейсов, которые тесно связаны для решения какой-то проблемы, я понимаю, да, ага, вот они вместе сбдоми образовали. Вот. И вот мы смотрим на этот ншминг и стараемся понять, где у нас внутри него вот этого длинного процесса какие-то подпроцессы завершились, да, допустим, он там за отправил отправил заявку, да, потом с ним потом он, допустим, пошёл и купил курс, оплатил, да, потом он был зачислен в группу, потом он, допустим, а сдал там первый модуль, а потом он там до экватора дошёл, да, потом он дошёл до конца, потом она ставила обратную связь, потом сделали рекомендацию и потом, не знаю, купил второй курс. Вот. То есть у нас весь процесс состоит из каких-то, на самом деле, подпроцессов, под под частей. И вот эти вот конкретные подпроцессы, которые решают конкретную проблему, допустим, решение проблемы, что человек оставляет заявку, да, можно сказать, что это отдельный субдомен, который работает с привлечением людей. И вот мы здесь как раз нам ДДД помогает. Мы выделили вот этот субдомена, сказали: "Да, вот он тут". Потом мы решаем проблему, допустим, его зачисления на курс. Да, это вторая проблема, там выбор курса. зачисления, да, там третья проблема, там, э, сдача первого модуля, тре и так далее, обратная связь, рекомендация, рефералка какая-то, да, то есть это тоже какие-то под процесс, который решает конкретные проблемы. И вот мы всю нашу компанию, да, мы на неё смотрим не просто типа компания, которая продаёт курсы, да, мы думаем: "Ага, а как она это продаёт? За счёт чего? За счёт привлечений, за счёт рефералки, за счёт ээ обратной связи, рекомендаций, ещё чего-то. И вот мы делим его на какие-то субдомены. Дальше мы уже переходим к Извини, проскочили. Да я знаешь почему? Потому что у тебя профессиональная есть такая штука. Ты знаешь очень хорошо эти термины такой субдомен. Субдомен. Ты знаешь, очень многие люди, когда вот сейчас нас слушают и они не знакомы с ДД, они будут думать, какие субдомены. Под домен в смысле домена? То есть мы же термин домен даже не ввели. Тут, наверное, очень важно сказать о том, что когда ты об этом говоришь, люди, которые вообще эту терминологию используют, домен - это предметная область. Это не в смысле домен в браузере. мы там вбили. Вот. И это просто общее понятие. То есть у нас предметная область, вот мы работаем с одним, с другим. И субдомены в этом смысле - это не поддомен. Ну да, давай дадим определение, да? То есть домен - это суть бизнеса, да? Вот если вот любой бизнес берём и спрашиваем SEO, да, там или оунеры, да, то есть одним предложением, что ты делаешь? И вот он отвечает не предложение, что он делает, это домен, да? То есть, допустим, я продаю самый лучший кофе, я делаю самые лучшие курсы, я делаю там доставку, я там делаю, не знаю, финансовые услуги продаю. Вот. А субдомена - это деление вот этой основной предметной области на какие-то конкретные направления, которые суммарно образуют эту компанию, да? Допустим, если мы говорим, допустим, про продажу кофе, да, то это условно нам персонала, разработка рецептов, закупка этого кофе, а хранение этого кофе, да, ну и так далее, и потом наливание в стаканчики, продажи. То есть вот всё это вместе вот эти отдельные поднаправления образуют компанию. И вот ДД, да, поскольку он двигается от предметной области, одна основная основная из его задач, да, на стратегическом этапе - это посмотреть, что делает компания, и постараться её разделить на вот эти вот, э, на субдомены вот с целью, а, того, чтобы каждый субдомен уже завернуть в конкретную IT-систему и потом решать его проблемы, ну, в достаточной степени автономно от других субдоменов. Допустим, если у нас есть, к пример, какая-нибуд бухгалтерия, есть там привлечение клиентов, да, ну вот, конечно, они как-то связаны, но не так сильно, чтобы мы это делали как единую доменную модель. Мы это можем делать как две разные доменные модели. Чтобы понять, что это две разные, вот нам нужно как раз компанию проанализировать, чтобы понять, из чего она состоит, из каких судоменов. Вот. Но чтобы понять, из чего она состоит, нужно покоммуницировать, да, вот с этими ребятами. Вот, как мы начали говорить, что я соберу всех разработчиков и маркетологов, и мы разрисуем процесс, да, потому что, чтобы компания, она достигает какой-то цели. И вот как раз, чтобы этой цели достичь, зачастую вот эти все субдомены в этом и участвуют. Потому что если какой-то субдомен в этом не участвует, да, возникает вопрос: а зачем он вообще нужен в этой компании? Можете его тогда распустить, и он нам не нужен больше. Вот. И вот именно поэтому этот процесс разрисовыван, чтобы понять, какие у нас собмены участвуют, и понять, где их граница, да, где работа одного завершилась, началась работа другого, да, его завершилось, начинала работа третьего. Вот поэтому вот, да, я разрисую вот этот процесс, выделю субдомены, обнаружу их. Вот как их обнаруживать, это уже дета достаточно такая, там есть много разных правил, мы сейчас не успеем всех обсудить, по каким критериям это нужно делать. Вот это тонкости, вот их обнаружи. Потом уже мы подумаем про баун контекста. баund контекст, да, давай тоже, наверное, термин сразу дадим, да, то есть это имплементация этого субдомена, да? То есть если у нас есть какой-то субдомен, да, то мы можем его имплементировать в виде одного баунт контекста либо нескольких баун контекстов. То есть, говоря простым языком, субдомен - это область проблемы, которую мы решаем, а boутекст - это решение конкретное проблемы. К примеру, вам нужно доехать из точки А в точку Б, да, вы можете, это ваша проблема, это субдомен. Конкретное решение какое может быть? Просто пойти, не знаю, по компасу. Баo Компас - это баункок, да, по сути, вот стрелочка с с полюсами - это конкретное решение проблемы. Дойти в правильную точку. Вы можете другой взять вариант, да, решения этой проблемы. Взять карту, пойти по карте. Вы можете взять навигатор, пойти по навигатору. Вы можете идти у людей спрашивать, как вам дойти, да? То есть у конкретной проблемы есть множество решений. И конкретное решение, оно имеет специфику, да, компас сильно отличается, вот если мы будем автоматизировать компас, да, и делать конкретную программную систему, которая компас по сути нам даёт, там будет понятие север, юг, стрелочка, куда она показывает, циферблат. Если же мы будем делать систему, где мы просто будем у людей подсказки спрашивать, а там будет понятие человек, что нам ответил, да, правильно, неправильно и так далее. И здесь мы как раз подходим к важной такой модели, что в каждом баунт контексте своя доменная модель внутри. Вот поэтому может быть так, что у одного субдомена один баунко контекст, то есть одна проблема есть одно конкретное решение, а может быть одна проблема множество решений. Вот. Но в 95% случаев всё-таки в реальном бизнесе у одного субдомена одно решение, да? Если мы там что-то делаем, то вполне конкретным способом. Если мы привлекаем людей, то вот таким-то способом. Вот. А, поэтому дальше я бы уже переходил к баo контекстам, то есть другими словами, а, переходил к формированию доменной модели, да, то есть какие у меня должны быть сущности для того, чтобы мне автоматизировать вот этизкейсы, которые входят в этот субдомен. Вот у меня бы развалось по доменной модели, ну, дальше уже там переходил бы к техническим схемам. Я вот тут бы, ну, не то, что поспорил, но хотел вот прямо идти по слоям с кейсами, да. Вот мы берём опять же производство курсов. Тут, конечно, сразу хочется сказать, вот как пример, да, у меня компания, чтобы ты понимал, 7 лет работала в режиме четыре человека. И вот то, что многие вещи, которые рассказываешь, это просто эволюционно. То есть я заранее не этого не знаю, мне не с кем собираться. То есть, скажем, я переосознавал вообще всё, что я делаю там буквально каждый год. То есть я вообще стартанул в тринадцатом году, то есть только в девятнадцатом у нас первая реклама была запущена. И когда ты говоришь, что вот только один способ привлечения, ну, это не совсе совсем не так, потому что у тебя наоборот как бы именно это и есть главная задача. у тебя способ один, он перестал работать, потом другой. Но это задача маркетологов, это не продуктовая история самого сайта. И вот что я здесь вижу. Я вижу как бы немножко разные уровни, потому что когда ты говоришь на уровне, давай назовём это словом предприятие, хотя речь идёт про любого уровня бизнес, да, даже ты берёшь какой-то маленький бизнес, у тебя есть, очевидно, бухгалтерия, но мы как разработчики в таких системах, как, ну, вот берём какой-то малый бизнес, там не существует разработчика и бухгалтерии, потому что бухгалтерия просто делается либо в 1С, либо ещё в какой-то системе. Эти люди просто живут там в своём жизни. Им иногда какие-то, может быть, выгрузки нужны, что-то что-то сопоставить, там с платёжкой соединиться, да, но в целом ты не разрабатываешь для них ничего. То же самое маркетологи, они на тильде сделали сайт. Всё остальное внешнее по отношению к тебе. Максимум иногда там какие-то им события тоже не твоё. Я это к чему? К тому, что на этом уровне это уровень немножко не тот. То есть вообще в целом разработку здесь и не факт, что подпустят. Типа чуваки, вы как бы вот ваша платформа, вы и занимаетесь, а там с бухгалтерие, со всеми остальными разберёмся. И поэтому получается, что у тебя как будто бы несколько уровней. У тебя есть уровень компании, на который там нелинейные разработчики вообще участвуют, их туда просто никто не позовёт. И у тебя есть уровень уже внутри платформы. И вот внутри платформы ты можешь сказать, что у тебя есть отдельно билинг, у тебя есть отдельно система прохождения курсов, у тебя есть отдельно система сопровождения курсов, у тебя есть отдельно система наполнения контентом, да? А ещё вне как бы технической части у тебя есть, например, система отбора авторов и создания контента, который в принципе делается в Google доках. Вот тут вот надо понять, да, что то есть, короче, уровень разбиения садоменов компании и уровень разбиения садоменов внутри уже софтины твоей, это как будто две разные вещи. Вот что я хотел сказать. Ну нет, здесь, слушай, я не соглашусь с этой историей. Смотри, во-первых, давай начнём ещё раз про ДД, где вот вот основная проблема скрама и у всех товарищей, кто скрам продаёт, в том, что они бегают и говорят, что он нужен всем. На самом деле он не всем нужен. Он нужен конкретным ребятам, у которых есть конкретное неопределённое будущее. И вот ими тогда нужен итерационный процесс, в котором они будут проводить эксперименты. А у кого там расписано на 10 лет вперёд планы по продукту, им это вообще не надо. И вот с ДДТ то же самое, да. Поэтому я сразу бы хочу подчеркнуть, что если как бы условно ты там стартапер с четырьмя людьми и у тебя половина ээ, скажем так, продуктов - это готовый коробки, да, вот если говорить про меня, у меня все продукты коробки. Я ни один продукт и сам ни одной строчки кода не написал, да? То есть это всё готовое коробочное решение, за которое просто плачу какие-то деньги. Угу. И у меня всё работает, да, на курсах это всё замечательно. Биллинг отдельно, бухгалтерия отдельно, привлечение 100- 500 каланов, там всякие воронки, интеграторы, всё, всё это работает. Всё работает, да. Угу. И у нас нет проблемы, да? Нет проблемы. Мы сынтегрировали кучу разных систем, собрали из них вот какое-то вот что-то, и оно работает. Это, по сути, вот код, но код разработка, другими словами. Но, да, если мы идём за дальше, да, нас не четыре человека, нас 400 человек, и мы ставим себе как бы амбицию стать, э, платформой номер один в мире, да, то мы уже не можем себе позволить на каком-то ноукоде вот это всё делать, да, мы уже хотим интеграцию своей бухгалтерии, которая будет работать вот так-то, да, своей днски, не какой-то там сторонней коробочной, да, там в банке, а своей, со своей системой, чтобы там автоматом была интеграция. Мы хотим, чтобы, когда человек, допустим, там оставлял заявку, чтобы у нас автоматом это в нашу CRM попадало. Наша CRM должна была такая быть, как у нас, а не такая, как нам предлагает коробочная. Вот. И когда у нас есть вот эта действительно большая система, у нас уже возникает здесь реально проблема. О'кей, а как нам это всё дело разложить по полкам, чтобы это всё не превратилось в один большой кусок грязи? И вот здесь нам ДДД нужен, да? А, а если у тебя, ну, там 80% готовые коробочные сервисы, да, то как бы у тебя нет вообще, в принципе, проблемы, чтобы думать про ДД. Поэтому мне кажется, мы либо кейс взяли не очень удачный. А я тебе дальше расскажу. У меня есть дальнейшее развитие как бы этой идеи. Берём любой, ну, у меня, наверное, средний, наверное, всё-таки, потому что мы тоже дошли до каких-то оборотов и в компании было, ну, там уже под 100 человек, но, допустим, берём крупные компании, там, скилбоксы и так далее, да, или там международные. Я не знаю, сколько ты в курсе, сколько в этих компаниях людей работает, но там работают тысячи людей. Тысячи. То есть это большие компании. И вот когда ты про это говоришь, тут, мне кажется, чуть сложнее всё устроено. То есть нет такого, что у тебя определённый уровень и ты всё пилишь сам. Ну, например, возьми продажи. У тебя даже в огромных крупных бизнесах, как правило, используют готовые сиремки. Сами никто ничего не ставит. То есть, например, все эти компании, в которых лидов там десятки тысяч в месяц, это много, да? А у тебя сотни продавцов, то есть это одни из крупных отделов продаж вообще среди всех компаний, которые есть, например, банально в России. Они используют. Ну да, давай это этот момент разберём. Смотри, вот мы когда говорим про DD, да, мы начали говорить про эти субдомена, да, DDD, ну, тоже даёт ответ на этот вопрос, да, там есть вот эти субдомены, они делятся дальше, да, они делятся на три вида, да, это Core sub субдомен, supporting subбмен и generic subбмен, да, то есть на русский язык перевожу Core. Что это такое? Это вот прямо то, что моя уникальная компетенция, да, вот если я делаю огромную образовательную платформу, что является моей отличительной компетенции от любых других платформ. То, что я не могу отдать на outsource, то, что не могу купить где-то, потому что другие-то тоже могут тогда купить. А вот вот именно моя фишка, вот Core - это наша собственная разработка. И здесь вот, э, именно разработка и разработка в стиле dдd прямо вот 100% э хорошо заходит. Суппортинг - это что-то второстепенное, без чего, как бы компания будет работать, но не так эффективно, как могла бы. Допустим, ну, не знаю, там взять тот же, ну, ту же бухгалтерию там или ещё что-то, если она неэффективно там выбивает чеки, долго делает какие-то там сводки, ну, о'кей, хорошо, он их долго делает, человек просто дольше на работе сидит или нам может три человека вместо одного. Но в целом у нас клиенты учатся, хорошие отзывы оставляют, все счастливы. Вот поэтому это бухгалтерия - это такой суппортинг, который как бы не фронтовая часть. Вот её можно либо на аутсорс отдать, либо там длам отдать. Вот пусть они там варятся там. Не факт, что нужен. Возможно, возможно нет. И есть Generic, да? Generic - это всё то, что можно купить. Вот. И это, да, действительно, тоже набор судоменов, которые присутствуют, но их можно купить. Вот. И в том кейсе, котором мы изначально разбирали, вышло так, что у нас всё дженериком оказалось. Мы можем всё купить и всё. Нам не нужно ничего разрабатывать. Вот. Но вот в крупной компании, да, что-то действительно можно взять как коробку, да, там сирмку как коробку, там одинску как коробку, ещё что-то. Система саппорта, как правило, никто сам не пишет, да, саппорта, да. Но с другой стороны, да, у нас вот появляется, допустим, там Telegramбот, который тоже является саппортом. И вот человек пишет Telegramбот, и он ему начинает отвечать. Вот коробка не предлагает такое решение, а вот нам надо. И мы начинаем уже как бы это делать и думаем уже вот это Telegramбот, это наш кор ключевая компетенция нашей компании или второстепенная? Вот. Ну, скорее всего, это суппортинг опять же у нас появляется. Тем более сейчас это везде есть уже, да, скорее платформа, да, скорее платформа, да. Поэтому тут как бы, во-первых, да, тезис, что ДДД - это про что-то масштабное, и второе, нужно уметь делить на вот эти три вида субдоменов. Вот если у вас всё оказалось дженериком, ну, как бы тогда расслабьтесь, просто покупайте и работайте. Вы тогда, скорее всего, стартап. Если крупная компания, вот там уже это имеет место быть. То есть нужно применять технологию под проблему, да. И самая, мне кажется, ну м плохая, неграмотная вещь, когда какую-то технологию применяют не к месту, да, вот такое вот часто бывает, а потом бегают по интернетам, говорят, что это полная фигня, это не сработало. А в этом-то и проблема, ты сам знаешь, да, что именно скрам ДД очень часто некие последователи любят вот типа ребята без этого вообще код трэш. Ну вот поэтому, да, мы здесь на этом подкасте будем честными, да, и честно сказали, что где ДД заходит, а где лучше его не надо использовать, и там вы только себе проблемы создадите. Угу. Я тебе тогда следующий вот этап развития. Я к тому, что, грубо говоря, мы вот как раз пытаемся с самого низа идти, чтобы понять, в какой момент это возникает. То есть, допустим, а мы всё равно не говорим про крупную компанию. Почему я не хочу про это говорить? Ну, мы сейчас, знаешь, вот всё равно очень многие ребята работают, ну, в разных компаниях, скажут: "Ну, блин, чуваки, 400 программистов, да, банки, классно, но кроме этого большой мир ещё есть, да, есть ребята, которые AVВИiAes делают, есть ребята, которые таймпад делают, есть ребята, ну, то есть много ребят, которых там, ну, не знаю, 20-50 человек, вот они все те самые сервисы, хелпдески, там не работают сотни программистов, а их хелпсков миллиарды. У тебя система тайм-менеджмента, тайм-трекинга, учёты калорий, это всё системы, в которых по полтора программиста работает. Их много, и они все вокруг нас. И это не интерпрайз, да. Ну, смотри, да, ну, здесь надо по-другому смотреть. То, что если ты, допустим, делаешь образовательную платформу и для тебя CRM - это Generic Subd и ты его можешь просто купить, то для ребят, которые делают CRM - это Core subбмен и они у себя могут внутри применять DDD. Угу. Вот так вот. То есть у тебя в разном бизнесе что-то может являться корсу sub субдоменом. Те ребята, которые делают таймпад, да, то есть для тебя это просто сервис, который ты просто покупаешь, для них это субмен и они заморачиваются. А что у нас такое там пилет, да? Что такое у нас конференция? Что такое участник? Участник равен билету или участника может быть по множеству билетов? И вот они с этим всем заморачиваются. Они должны выстраивать всю терминологию, доменную модель, решать эту проблему. Поэтому не нужно думать, что ДД в маленьких компаниях не заходит. Он заходит там, где у нас есть сложная предметная область и есть, в принципе, понятие этой предметной области. Вот. Э, а сервис может быть разного размера. То есть он может быть и там от пяти человек в целом вполне вы можете применять DDD, если вы делаете какую-то вот штуку не просто там, ну, достаточно сложную п платформенное какое-то решение, да, которое может, то есть это я именно это хотел подчеркнуть, что речь не идёт о том, что вот как в начале ты просто пример приводил, у вас там, значит, целый enterprise, обязательно банк и вот это всё, потому что вот реально есть эти перекосы. И как раз вот к этому сейчас хотел прийти. То есть получается, мы, грубо говоря, понимаем, что всё остальное, допустим, у нас решается сервисами, с которыми максимум мы вебхуми обмениваемся. Но тут как бы понятно всё, да? И вот, а, у нас такое было, и мы в какой-то момент понимаем, мы хотим пилить свою корплатформу. Всё, у нас есть бизнес, он дошёл до этой точки, мы не говорим, что он в ней был, он сейчас подходит, и мы такие: "Так, ребят, вот всё как бы хорошо, но мы, например, как на Хехлите реализовано, там практика в браузере, у нас есть там определённый фич, это довольно сложная техническая платформа, и мы понимаем, что какой-нибудь э, господи, как же он называется-то, знаешь, вот эта штука, на которой все инфоребята делают свои продукты. Господи, у меня из головы вылетело. Ну ладно. В общем, есть, короче, сервис, на котором они все это делают, причём зарабатывают огромные деньги, который предоставляет тебе всё из коробки. Ты просто на нём создаёшь себя и вперёд. Ну а Оле, как marкетпйс, только для а инфобиза, скажем так. Сейчас, господи, как они называются-то? Кошмар, я забыл. Ну ладно. В общем, короче, мы решаем сделать платформу. И вот в этот момент, собственно, происходит тот самый процесс. Мы давай ещё раз тогда попробуем продолжить эту игру. То есть мы говорим про то, что сейчас мы выделили один субдомен, и это история только про нашу платформу, но на самом деле внутри неё мы тоже субсуб домен начинаем выделять, потому что у тебя на платформе же есть опять же личный кабинет, у тебя есть ээ билинг, который внутрь надо встраивать. Это не, да, ты используешь какой-нибудь cloud payments, но извините, надо внутри пилить логику, да, ну и так далее. То есть у тебя система прохождения уроков, у тебя система создания практик, у тебя а система оценок и добавления в группы и вообще какая-то рассылка. Более дискретно начинаешь разбивать это всё дело. Э как бы у тебя не появляется субдомен в субдомене, у тебя просто появляются более дискретные субдоменны. Вот вся история. Угу. Понятие субдомен в субдомене, его в ДДД нету. Вот. А более дискретное, то есть если у нас есть вот такой субдомен, а мы его потом на два разбили, ну всего, у тебя просто два субдомена. Нет проблем. Не, ну с точки зрения бизнеса и твоего финансового директора всё-таки будет именно, что это отдельный, он не будет делить, что у тебя там внутри какие-то штуки, он скажет, что это просто платформа. Он может просто сказать, что у него есть продукт, да, вот наш продукт - это наш продукт, и тогда у тебя домен сузится вот до нашего продукта, а всё остальное это будет просто внешняя интеграция. Вот. Не, ну он то есть просто я про себя даже скажу, вот финдиректор у тебя, например, банально платформа - это отдельная штука, на неё есть своя там стоимость сопровождения программиста и так далее. А для программиста платформа - это отдельно билинг, это отдельно, ну вот всё то, о чём мы проговорили. Поэтому всё-таки с этой точки зрения, как ни крути, я логически не могу прийти к выводу, что оно просто делится. Оно скорее зависит, уровень абстракции зависит от того, кто на неё смотрит, на эту систему. Ну да. Но здесь, на мой взгляд, мы тоже должны делать э мапинги между, скажем, людями от бизнеса, да, и технарями, потому что если у нас у технарей будет одно понятие платформа, а у них другое понятие платформы, мы придём к той же самой примерно проблеме, как и с терминологии. Вот, на мой взгляд, вот, э, поэтому я здесь не сильно бы разделял, на мой взгляд, архитектура, она очень сильно бьётся с оркструктурой. Вот, и с продуктами она хорошо бьётся. Вот просто нужно, чтобы все продуктовые термины смапить по пониманию там с техническими терминами. Фендер не разговаривает с разработчикой, просто, чтобы ты понимал, он другими понятиями мыслит, у него потоки финансовые, там, вот это всё совсем по-другому. Ну, как бы с техдиром-то он нара разговаривает. Вот. Надеюсь, нет. Они на другом уровне работают, им это не интересно вообще. То есть у них конкретно есть статьи расходов и доходов. Это всё, что их волнует. И то, как ты налоги оптимизируешь. Ну, в смысле, где-то теряешь, где-то не теряешь. Ну, ладно. Но это уже, возможно, другая какая-то конкретная, да, конкретная компания с конкретными своими договорённостями, да. Но если мы там будем говорить про тот же самый там The Wops, да, я помнишь там проект Феникс, возможно, читал. Угу. Там было один из чуваков, да, который в этой книге, он типа занимался инфобизом, и он ходил постоянно компанию всю тряс, да, и что они там всё делают неправильно. Где-то в конце книги он понял, что типа задача не трясти компанию, а делать так, чтобы у компании просто проблем в инфавизи не было. Вот. А он это понял после того, как он начал активно коммуницировать со всеми людьми в компании и понял, что они вообще, какие у них есть проблемы, как они их пытаются решить, может ли он им помочь и так далее. Поэтому, ну, всё-таки, конечно, ну, класс там что-то кто-то с кем-то не коммуницирует, но я думаю, что если бы коммуницировал, было бы только лучше. Ребят, напишите, пожалуйста, что вы об этом думаете, потому что здесь уже очень интересно, потому что на разных уровнях очень разные вещи происходят. То есть в моей, э, картине мира, например, то, как я знаю, эти люди работают, например, когда мы говорим про финансовый блок, они вообще им параллельно, что у тебя есть или нет технорий, они работают вообще в другой немножко картине мира. Они там с фаундером общаются на другом совершенно языке. И даже, кстати, вот тоже пример могу привести. У тебя есть бухгалтерская, у тебя есть управленческая отчётность. Ты должен это прекрасно знать, да? Это абсолютные разные вещи. И, например, бухгалтеры очень часто не понимают управленческую отчётность, не думают в её категориях, и требовать от неё её понимания просто невозможно. И, например, когда часто об этом говорят, у тебя есть прямо чёткое разделение. Есть финансовый блок, есть финансовые менеджеры и финдир, и есть бухгалтеры, которые вот могут там про какие-то такие вещи говорить, типа про конкретный там кэшфлоу, про конкретно сдать какие-то вещи прямо сейчас, но не видеть, например, картину в целом, которую видит финансовый директор, потому что он смотрит совершенно другим способом на то, как у тебя какие там модели, планы и всё остальное. И это то же самое можно к маркетологам применить и к остальным. То есть всё-таки у тебя система, в которой все всё знают, все всё понимают, она даже на небольших объёмах уже становится невозможной. Да. Не, речь не говорит нет о том, чтобы все всё понимали, да? Речь о том, что вот как раз мы, когда говорили про вот субдомены баун контекста, да, вот как раз баун контекст - это конкретное решение, да, вот если мы вот хороший, кстати, пример-то накинул, вот у нас есть условно там платёжка или проводка какая-то, да, вот она есть как в судомее, да, но конкретные баунконтексты могли бы быть, к примеру, в управленческом отчётности, как это отразиться, как это в бухгалтерской отразиться, как это у маркетологов отразиться, да, маркетологам нужно там какой-нибудь, э, юнитэкономику показать, да, там, э, бухгалтеру просто там приход в управленческий там ещё что-то. Вот. И странно было бы им показывать одно и то же. Это вот как раз пример, когда у нас есть какая-то проводка и есть три конкретных решения, три конкретных баунконтекста под конкретную аудиторию, вот, которые решают конкретную проблему. Вот. Ну, мы начали с разбидоменов. Вот. Поэтому, да, субдомер большой, можно разбить на более мелкий, разбивать до того момента, пока он не станет чем-то конкретным, да, который решает, в котором есть какая-то конкретная проблема. который можно автоматизировать. Я, кстати, хочу усилить можно там до бесконечности, да, усилить твой pointт, который явно тоже тут всё время идёт, но если вот не проговаривать, можно не до конца понять, что у тебя действительно понятие пользователя с точки зрения бухгалтера, с точки зрения финдира, фаундера, учителя сопровождения, саппорта - это совершенно разные вещи. И это отражается реально на коде. Про это часто как раз и в книжках везде рассказывают, что у вас есть понятие пользователя, но на самом деле в разных бан контекстах это разные может быть, да, то есть это уровень настолько разный, что у тебя разный набор полей, разные представления, разные форматы с ним работы и так далее, что рождает даже, то есть как ты разбиваешь не даже не не на уровне микросервисов, а внутри с точки зрения сущности, с которой ты работаешь. Прав ли я? Ну да, да, да, всё так. Это как вот тоже вот история жизни. Сегодня в одном блоге прочитал, что компания решила следовать принципу DRI, да, don't repeat yourself, да, и то есть вообще, чтобы сущность была в едином экземпляре вообще в системе, не было вот как раз такого, что вот у нас есть разные проекции юзера. Вот если юзер только один, там примерно над заказом, короче, да? И то есть сделали один заказ и в нём там 150 полей. заказ там, начиная от того, когда он был создан со всякими там проекциями на бухгалтерию, на всё-всё-всё, в общем, там набралось огромное количество полей. Вот. И в конце как раз была шутка, что принцип драй привёла к мокрой луже слёз разработчиков. Вот. То есть, э, да, в этом вся и фишка, что вот мы вот в начале говорили: "Да, зачем этот ДД нужен, да, вот нужен он, не нужен, да, разработчик же всё понимает". Но я видел тоже множество систем, где условно люди старались вот следовать принципу Don't rep itself, да? пытаться строить какая-то вот системы, в которых есть, э, я не помню, как этот подход называется, но, скажем, где сущность в одном экземпляре. Вот и не может быть там несколько разных не м когда в базе данных а ты делаешь, а это может быть ты хотел только один источник истины и больше нигде у тебя нет его. То есть, если тебе нужно, допустим, обратиться к заказу, то вот обращаешься всегда в одно конкретное место. Если тебе нужно обратиться к юзеру, то обращаешься во второе конкретное место. и так далее. Вот. Э, и то есть это фоку фокус на данных, на то, как они хранятся. Вот. И там сильно растектора заморачивались на тему вычленения как раз вот этих вот сущностей, какие у нас там должны быть. Но проблема в том была, то, что они полностью игнорировали вот как раз проекцию этих сущностей на конкретные, скажем так, баун контекст, на конкретные м, скажем так, области решений. Вот. И в итоге в одной из сущности она превращалась в GT Object. В ней появлялось огромное количество полей. В ней, мало того, полеет ещё полпроблем. В ней появлялась куча методов, которые друг другу просто противоречат, да, ты просто хочешь создать, а чтобы его создать, тебе нужно заполнить кучу полей, которые тебе вообще не нужны для создания для именно в твоём процессе, да, другому человеку нужно что-то другое. В общем, это полная дичь. Куча разработчиков единую сумечность правят. Баги, слёзы и проблемы. Вот. И вот как раз возвращаясь к началу нашего диалога, да, DDD как раз вот как подход, да, он говорит сразу: "Ребята, ну да, вот так, конечно, можете сделать, но просто не надо. Посмотрите на компанию, посмотрите, какие у них есть субдомены, из чего она состоит. Выделите баoунд контекст равно баound контекст - это отдельная доменная модель. Испроецируйте эти сущности в эти отдельные модели. Если вы решаете проблему маркетинга, пусть пусть у вас будет заказ в маркетинге, юзер в маркетинге. Пусть там будут только те поля, только то поведение, которое нужно в маркетинге. И нет проблем, как бы тогда. Да, у нас появляется какое-то аля дублирование, но зато у нас появляется гибкость, да, если ребята в маркетинге захотят к юзеру добавить какое-то плюс одно поле, а в заказе убрать два поля, ну, они их просто уберут. Метод поведения, да, и мы никак не повлияем там на бухгалтерию, на всю остальную часть компанию. Появляется гибкость, да, гибкость, что это высокая скорость разработки, развития и плюшка для всех. Вот поэтому это нерв на поверхность к этому приходит только через годы опыта. Ну вот, ээ, как раз ДД, я вот поэтому говорил, что это вот для людей синер Синир плюс и выше. Вот когда уже над таким вот на такие грабли напоролся пару раз и думаешь: "О'кей, а где выход?" Ну вот он тут. Пару прикладных примеров с этим связанных. А как это проявляется в реальности? Для того, чтобы приземлить, потому что иногда это может абстрактно звучать, то, что мы говорим. Действительно, например, если мы заходим, вот я про свой проект скажу, да, на Хекс заходишь, у тебя есть много админок. У тебя есть админка для маркетологов, админка для тех, кто создаёт контент, тех пятых, десятых, и у всех абсолютно в этой админке есть свой собственный юзер. То есть это тот же самый юзер, но это его контекст, в котором его поля, его способ изменения и только его выделенные вещи. В чём здесь ДД? в том, что если человек так не мыслит, опять же нева, он может не знать про ДД, да, но он может такой думает: "Ну, у меня же usер - это единая сущность, и вот она должна быть, и у тебя просто он появляется не в разделах там для маркетологов, для этих, а у тебя просто есть некая отдельная а урл, по которому у тебя просто изменяется юзер". И дальше туда пихается, естественно, всё подряд. И у тебя получается, что ещё появляется проблема разделения прав доступа, а кто что может менять и так далее. И поэтому, когда ты вот говоришь про сложность поддержки, наверное, я бы сказал, в первую очередь это ментальная сложность восприятия системы. То есть ты, когда, грубо говоря, над чем-то работаешь, идеально, когда ты думаешь в рамках какого-то контекста. Например, вот сейчас мы думаем только про биллинг, а когда ты на него смотришь и ты должен сразу одновременно все контексты в голове держать, не потому что ты знаешь слово контексты, а потому, что у тебя тупо всё навалено в одну кучу, то, конечно, возникает проблема. Там, правда, другой вопрос: а как типа по-другому? Но это интересно тоже. И ещё хотел добавить, это знаешь где ещё отражается? Вот с этим я сталкиваюсь вообще каждый раз, когда с кем-то разговариваю. Значит, если ты посмотришь сервисы, очень много в openсорсных сервисах это видно, чуваков, которые стараются опишку по ресту делать, почему-то у них в голове есть такое ограничение у многих ребят, что по ресту где-то написано или вот как-то они себе так видят, что у тебя, если есть крут для юзера, он может быть только один. И вот это вообще неправильно. То есть у тебя столько, сколько надо, их должно быть в зависимости от того, какой контекст используется. У тебя может быть закрытая пишка приватная, для мобилок, для то есть, ну, срезы могут быть разные в зависимости от ситуации. У бухгалтеров своё, у этих своё. И я часто видел, к чему это приводит. У тебя в Редмайне очень хорошо можно посмотреть, он м там прямо видно, как они это пытались сделать и к чему это приводило. У тебя, грубо говоря, один контроллер ростовый, да, который отдаёт какие-то там экшены. У тебя, естественно, экшенов там 500 экранов, ну, прямо много. Не три экрана, а десятки экранов. И знаешь, чем у тебя увешано? Всё, у тебя сверху огромное количество, а, талбэков, ну, которые запускаются при попытке обработать, чтобы проверить, если текущий пользователь это, то вот перечисление с десяти методов, которым можно получить доступ. Если у тебя это, то вот это. То есть у тебя появляется огромное количество неявной логики, которое пропускает сквозь вот эти вот ограничители, чтобы понять, а можешь ли ты туда пойти, если можешь, что ты можешь поменять и так далее. Вместо того, чтобы сделать, да, больше будет контроллеров, разделены по разным урлам, но у тебя сразу с точки зрения кода будет видно, что ифов просто нет. То есть это вот только для них и здесь только их. Это только для них и здесь только их. И код сразу становится реально сильно проще. О нём проще думать, проще менять. Дублирование здесь, ну, я бы не сказал, что его много, особенно если у вас нормальный статический язык с рефакторингом, вы ещё и быстро всё это поправите и увидите, если что пошло. Ну, в целом, да, я тоже уже давно придерживаюсь концепции, что дублирование - это не самая большая проблема, как бы в кодировании. То есть вот 10 ифов или 10 методов, я лучше сделаю 10 методов. Вот. Ну, тут всегда, конечно, контекст важен. Просто одно, когда ты действительно Да, да, да. Ты, то есть, когда ты опытный разработчик, тут скорее вот как сейчас мы многие вещи говорим, то есть я понимаю, что ты рассказываешь про них просто потому, что у тебя дофигище опыта, да? А человек, который может слушать, он вообще может не понимать какие-то просто какие-то слова, набор слов какой-то он слышит и всё. Вот. И поэтому ты, когда у тебя уже там типа второй десяток лет опыта, ты такой: "Да что тут думать-то?" Да? То есть вот в этой ситуации надо делать так. То есть у тебя просто такое количество кейсов, как, наверное, у шахматистов в голове, что вот прямо встретиться совсем с новым контекстом, это ещё постараться надо, когда ты вообще не понимаешь, типа, а как в принципе могла бы такая система быть устроена? Ну, если ты не всё время на заказ делаешь. Кстати, даже вот я пример приведу для тех, кто не в курсе. Вот если мы берём чуваков, которые на заказ работают, вот когда только на было зарождение всей этой истории, когда вебстудии появлялись, агентства появлялись, они делали всё: мы делаем сайты, потом у тебя появилось разделение, кто-то больше про дизайн, кто-то больше там раскрутка и так далее, да? А потом ещё появилось разделение, то есть у тебя эти компании начали по сути специализироваться на этих областях. Есть люди, которые специализируются накоме, есть люди, которые специализируются на инфобизе, есть люди, которые специализируются на строительных компаниях. Почему? Потому что то, что бы мы сейчас с тобой не обсуждали, какой бы классное ДДД не было и вообще какие-то способы ивристики всё это понять, жизнь показывает, что если ты ни разу не строил эту систему, мм, как бы ты не старался, всё-таки это будет не тот уровень, когда приходит чувак и говорит: "Я только что три запустил интернет-магазина, давайте мне четвёртый". Ну то есть и да, и нет. Вот это, ну я, конечно, мы не берём всех подряд, мы берём про тех, кто реально на хорошем уровне сни. Я согласен, да, что вот мы как раз подсвечиваем интересный момент, да, что вот, э, есть люди, которые фокусируются на технологии, да, есть люди, которые фокусируются на предметной области, да, вот и к чему это как раз привело, да, что компании, которая раньше фокусировалась там в веб-разработке, дизайне, да, на сегодня они делятся по другому принципу, да, по принципу мы делаем marркеetплейс, мы делаем интернет-магазин, кстати, сейчас иишки, там ещё что-то, да? То есть мы спецы в этой предметной области. Почему? А потому что как раз, что понять предметную область гораздо сложнее стать экспертом, да, чем понять просто какой-то там новую технологию, да, которую можно выучить там за месяц, за два. Ну я утрирую, конечно, там за два там для там какого-то эксперта, да, там для кого-то за год, но всё равно. А стать экспертом в построении, допустим, там интернет-магазинов, да, ну тут за год будет сложновато, там нужно побольше поработать. Вот. И да, действительно, плюс ещё в чём, да, что этим людям нужно меньше будет объяснять. ты к ним пришёл и они уже с тобой говорят в правильной терминологии, делают правильные вещи и так далее. И видели все эти штуки уже, скорее всего, да. Вот. Но с другой стороны, вот который там сказал пример, человек сделал четыре интернет-магазина, да, есть такой, а, тоже интересный кейс. Синьор - это если человек синьор и 15 лет делает одно и то же, он является синьором. Или тот, который каждый год делает что-то новое, он является синьором, да? То есть у кого опыта больше. Вот поэтому тут тоже есть такая вторая сторона медали, да, что если человек, ну, условно одну и ту же задачу решает 15 лет и больше другие задачи не решал, то, возможно, как бы он и очень узко мыслит, как бы, а мир гораздо шире. Поэтому тут тоже как бы две стороны медали, да, там можно ещё сказать, что кто долго работает на одном проекте и видел эволюцию проекта и как раз упирался в архитектурное решения, для меня во многом, конечно, это тоже важно, потому что если ты год работаешь, ты никогда не упрёшься в то, что а произойдёт. Поэтому я бы тут дополнил, когда ты говоришь про знание предметной области, я бы дополнил не просто знания, а даже само знание предметной области. Ну, допустим, вот мы бы с тобой сейчас могли с тобой разобрать какую-нибудь область, в которой мы разбираемся, и довольно неплохо могли бы это, наверное, сделать. Но нас слушает много людей, мы бы сказали: "Попробуйте заимплементе". Дело в том, что на практике очень часто бывает, что просто после использования какого-то ты понимаешь, что, например, вот эта часть более подвижная. Тут, на самом деле, стоит предусмотреть возможность подмены, потому что у тебя сегодня одна платёжка, завтра вторая. Но при этом, когда мы разбираем саму предметную область, мы можем изначально даже, ну, не проговаривать вся такие кейсы. Поэтому для меня здесь вопрос ещё того, что человек попробовал и понял, что даже то, что он придумал, оно и должно быть каким-то определённым образом имплементировано, чтобы не наткнуться на стандартные проблемы. Кстати, регуляция вот вполне. Ты можешь очень классно всё придумать, сделать, запускаешь, а тебе приходят и говорят: "Чувак, ты забыл, что у тебя есть регуляция. Ты не имеешь права так делать. Или ты обязан сделать вот эту штуку". А, ну давай. Удаление пользователей. Ты на территории любой страны, ты знаешь, что на территории любой страны есть правила. Ты не имеешь права полгода, ну, например, в России такое правило, я знаю, в других странах там свои правила. Ты, если пользователь даже говорит: "Удалите, сделайте мне кнопочку". и хочет, чтобы ты удалил и будет на тебя там наезжать, ты физически не имеешь права полгода удалять всё, что он там сделал. А выяснить ты можешь только тогда, когда к тебе уже придут органы. И вот таких вот штук я могу там очень-очень много рассказать, которые ты вот так вот заранее не поймёшь. Поэтому реальная жизнь, она ещё чуть сложнее, да? Да. Но здесь, на самом деле, даже вот когда мы говорим там про доменные модели, на самом деле, да, вот ещё одна такая ловушка, ну, скажем так, начинающего архитектора, проектировщика, да. А что думают, что с первого раза всё получится идеально, вот как надо. Это на самом деле не так. Ни у кого даже художники, да, которые рисовать, рисуют картину, вы знаете, что у них рисуют, потом через 5 лет приходят в галерею прямо и дорисовывают. Ну вот раньше такое было, вот я читал. И здесь то же самое, да? То есть у вас, э, вы можете разработать доменную модель, потом понять, что вы где-то какую-то концепцию неправильно поняли, вы её дорабатываете, и это нормально, да, потому что вы как бы более глубоко погрузились в предметной области, более глубоко её поняли, поняли, что можно сделать лучше, сделали. Это как бы, скажем, вы так поправили. Но если поменялся бизнес и вам из-за этого нужно менять доменную модель, то это наоборот плюс, а не минус. Это так и должно быть. Вся фишка ДДД в том, чтобы IT-составляющая соответствовала бизнесу. бизнес меняется, доменная модель меняется, он ещё раз поменялся, она ещё раз меняется. Нет никакой магии, что бизнес меняется, у вас код не меняется. Вот просто это как раз явно выражено, да, что если у меня было там два тарифа, там, допустим, они были такие-то и такая-то формула, да, потом формула поменялась, я должен поменять или там у меня добавился новый способ доставки, я должен его добавить. Вот. То есть, ээ, если мы не делаем какой-то там конструктор, да, где там менеджер может там точе, ээ, стрелочки всё все создавать, да, какой-то там конструктор сайтов, да, там о'кей, да, у нас есть конструктор, он может собирать вот только ограниченные вариации. А если мы делаем живой бизнес, да, в котором бизнес меняется, то IT тоже будет меняться. И вот фишка именно в этом, что мы наши доменные сущности, их поведение сопоставляем реальным бизнес-правилам, и они идут как бы в такт с жизнью компании. Вот. И это очень удобно, да, потому что идёт чёткое соответствие. Вс там поменялось, тут поменялось, всё, никаких выдумок и сюрпризов. Поэтому это норма, это нормально. И, кстати, это такой неявный посыл от тебя о том, что изменения в бизнесе надо воспринимать ну как минимум не негативно, потому что я думаю, ты тоже часто такое видел, когда разработчики просто прямо им не нравится это. Они такие: "Вы что, обалдели что ли? Мы только сделали, а вы тут уже пришли и у вас там семь пятниц на неделе". Сделайте свой бизнес, и вы увидите, как у вас будет 7 пятниц на неделе, потому что клиентам не прикажешь. У тебя клиенты завтра там конъюнктура поменялась, ведут себя по-другому, и ты побежал делать тоже по-другому. Вот это хорошая, кстати, тоже история, потому что иначе реально разработчики сами себе накручивают, страдают из-за того, что ой, у меня какой-то неправильный бизнес, он что-то там меняет. Ну это вот как раз мы возвращаемся к самому первому началу, что мы говорили, да, вот про коммуникацию между бизнесом и IT, да, вот если вот IT живёт в каком-то своём мирке, да, бизнес в своём мирке, и они думают, что там люди что-то не понимают, а мы тут идеальную систему построили, они нам сейчас всё разрушать будут, то это как раз две проблемы. Первое, что они как бы не общаются, не коммуницируют и, соответственно, они не понимают проблем одних и других. Раз. Второе, что айтишники не знают горизонта планирования, которое есть у бизнеса. Да, то есть они строят систему, а у бизнеса там уже какие-то новые задачи, новые какие-то проекты они там продали, согласовали, пообещали, а к айтишнику там только через месяц придут. Айтишник в этот момент строит какой-то самолёт какую-то в другую сторону совершенно. Да. Вот. А если же мы будем как вот изначально за что мы топили? за то, чтобы была чуть больше коммуникация, не обязательно там ходить прямо с ними, не знаю, там на коленку не сидеть, да, а вот просто, чтобы в целом в курсе мы были, какой у нас хотя бы стратегическое развитие нашего продукта, то уже команда разработки будет закладывать какие-то наработки на это развитие. И тогда, когда они к нам придут с этой задачей, мы уже будем не полностью всё переделывать, а мы будем просто по подтягивать к этому. Вот. Э, поэтому вот это мы всё время, да, касаемся тема, что корень всех проблем - это когда IT оторвана от ребят, от бизнеса. У меня есть фраза, которую я люблю повторять и немножко вкладывать в неё смысл, к которому люди не привыкли. А когда говорят про культуру компании, обычно там говорят: "О, а мы вместе ходим, значит, на шалки и играем в настольный теннис". Да. А я говорю: "Культура компании - это, ну, не я это придумал, просто мне очень понравилось, и я про это теперь всем рассказываю". Как раз оно в тему. А культура компании - это принятие решений без руководства. И это неявно как раз подразумевает то, что в зависимости от того, насколько у вас прозрачная система, все люди понимают, куда мы идём, какой у нас приоритет, идеология, философия и ценности, то если за тобой следить не будут, ты как раз на любом уровне. Во-первых, ты принимаешь то, что происходит, а не говоришь: "Фу, они ко мне пришли с изменениями, которые я считаю неправильными". А ну или, по крайней мере, можешь понять, почему это так сделано. А-вторых, ты, скорее всего, примешь относительно более-менее правильное решение. Вот то, о чём ты сейчас говорил. А потому что у тебя есть не всегда просто в бизнесе есть понимание, что вот мы идём туда, у тебя чёрные лебеди есть, сейчас вообще мир такой, что не загадаешь, да? Вон ишки пришли, все бизнесы посыпались, сейчас все же кардинально резко меняются либо умирают целой индустрии. Поэтому все эти планы, которые строили ещё мы 2 года назад, на самом деле они все ими подтёрлись, если уж так откровенно говорить, почти во всех индустриях. касаемо яишки и экономического состояния и всего на свете, причём неважно в какой стране, то есть плюс-минус. Есть, конечно, не какие-то фундаментальные вещи. Наверное, у людей, которые занимаются нефтью и электричеством, там всё чётки постабильней, чем вот в этих местах. Знаешь, что хотел сказать? Мне кажется, мы довольно неплохо. М, мне бы хотелось верить, что у нас был такой не просто теоретический разговор, как обычно, знаешь, это плохо, это хорошо, а мы через кейсы, через вот какой-то развитие понятий смогли немножко вот донести эту идею, концепцию, чтобы у людей не возникло ощущение, что ДДД - это некая вот просто отдельная фигня в вакууме, которую вот там какие-то фанатики и занимаются. Но мне при этом хотелось бы вот что сказать. Вот мы про это сказали. И как я вижу, например, э разработчиков, которые нас послушают, они говорят: "Ну, в принципе, логично. Я примерно так и думал, да, чуть больше сейчас мне понятийно стало понятней. Всё, спасибо, пошёл так и делать. Или другой скажет: "Я всегда так и делал". Можем ли мы сейчас сказать, что не, ребят, всё-таки вот то, что мы сказали, это больше такая типа философия, но в реальности там есть паттерны, подходы, правильные вопросы. Надо обязательно прочитать книжку и вообще вот в коде писать вот так, а а иначе всё это будет фигня. Вот что делать дальше им в этом плане? Угу. Эмонса читать. Давай так, упрощаю. Эмонса не читать. Вот. Ну не читать. Ну я простых словах, почему я так говорю, да? Смотри, с это как сложная литература, да? То есть к ней нужно прийти, то есть должна быть мотивация большая, чтобы к ней прийти. Вот. То есть я рекомендую почитать э вот книжку вот Влада Хонова. Мы про неё вот сегодня начали в начале, да, не помню, как она называется. Орейли там с обезьянкой такая книжка. Ну DDD Влад Хоноров. Вот она тоненькая, она поверхностная, но фишка её в этом, да? То есть это как такой, знаете, хук. То есть вы зашли на выходные, книжку прочитали, в понедельник вы уже знаете, про ДД достаточно, чтобы понять для себя, надо вам это или не надо. Вот всё это её задача. Если вы понимаете, что вам надо, вы начинаете уже идти делать как какие-то конкретные действия, да? Вы либо читаете другие книжки, либо идёте на курсы, да? К примеру, у меня есть курсы по ДД на Java, ДD на Ленге, ДDд на C-шарпе на трёх крупных языках. О'кей, мы там строим с нуля микроссервис, полным применением ДД. Нет проблем, в конце вы будете знать и чистую архитектуру, и ДД, и все тактические паттерны. Вот поэтому я рекомендовал бы начать с этой книги. Вот. А уже потом, да, когда вы поняли, да, мне это надо, вы вот идёте там книжки какие-то другие более сложные смотрите и так далее. Но, конечно же, всё через практику. Вот. Плюс, как я уже говорил, ДДД оно, ну, типа, вот есть три составляющие для меня. Это философия, где вот в целом про всё хорошее, против всего плохого, а стратегия, да, это то, как поделить компанию на субдомены, выделить обособленные контексты субдомена и конкретная тактика, да. Вот если мы говорим про разработчиков, да, то разработчикам, на самом деле больше интересна тактика, потому что, ну, разработчик не архитектор, разработчик не CTO, который принимает решение, что у нас новое направление появляется, новый продукт появляется, новая система появляется. Да, мы зачастую эту систему имплементируем. И вот здесь как раз у нас э возникает вопрос: а чем нам туда ДДдd может помочь? И вот мы как раз подходим к тактике, да, то есть э стратегия - это про выделение какого-то, э, крупного модуля, да, а тактика - это про то, как мы этот модуль внутри будем реализовывать. И в ДД есть конкретные паттерны, э, как имплементировать, э, сущность, то есть как реализовывать классы в стиле ДД, как делить разные сущности по типам. Как выделять логику, которая не относится никакой сущности? Как отделять логику приложения от логики домена? Как правильно реализовать репозитории, фабрики, юзкейсы? Как это всё с инфрой связывать, чтобы инфра не притекла в домен? В общем, там много нюансов. Вот. И это всё про тактический ДД, как имплементировать какую-то конкретную доменную модель в коде. Вот. А, и вот, наверное, разработчикам это вот в первую очередь будет интересно. Вот. Потому что здесь можно получить реальные профиты прямо вот в ближайший день, да, потому что мы писали вот в процедурном стиле, да, у нас наши сущности были мешками с полями, то есть датшки просто с атрибутами, без поведения. Мы немножко перестроили приложение, и у нас уже появляется более лёгкое тестирование, более дешёвое тестирование, более гибкие изменения, меньше тестов смоками, можем присоединять и отсоединять разные технологии. Ну, в общем, много плюсов появляется. Вот. И вот если разработчик, да, то я бы вот в эту сторону шёл, потому что стратегия и философия - это уже, ну, то, когда мы строим именно системы. Это больше интересно архитекторам CTO и людей, у которых болит именно от построения системы. Вот если вы пишете просто микросервис либо разрабатываете монолит какую-то его часть, то вам тактически ДД как бы вот то, что надо, скажем, как говорится. или те, кто слушает наш подкаст и воли неволи просто про философию. Да-дада, послушали. У меня сразу два вопроса. Первый вопрос. Понятийный аппарат, которым ты сейчас оперировал, он много включает понятий, которые не присутствуют во всех языках. А такой блиц вопрос: может, подходит ли ДД под все языки, со всеми моделями работы и способом организации кода с классовой, бескласовые, функциональные, императивной и просто люди, которые вот на них пишут, они сейчас такие сидят и думают: "Ну ладно, о'кей, на уровне смыслов ещё понятно, но по коду, слушай, я могу говорить только за те языки, которые я знаю. Вот на текущий момент это вот три, которых я назвал, да, это Goang, C#P, Java". Вот. Тут всё о'кей, да? C#P Java вообще нативно, да, потому что там есть классы, объекты, это языки, которые для разработки enterprise систем изначально было заточено, и там всё идеально ложится. Анг, э, чуть менее, но особо проблем тоже нету. Там есть просто есть нюансы языка, которые в целом даже без DDD с ними приходится там справляться. Допустим, отсутствие конструкторов. В ДДD есть понятие, что объект не может быть создан некорректно. И поэтому в Джаве, в Сишарпе мы просто берём и делаем приватный конструктор. Таким образом никто не может создать объект, кроме как через конструктор с полями. Вот всё в гунге как бы нет. Вот, то есть, пожалуйста, я через литерал могу легко его создать вот без ограничений, но это не проблема. Да, можно просто договориться внутри команды, сделать линтера и не просто, если конструктор, то использовать его, да, не пытаться себе в ногу выстрелить. Поэтому на горшке это всё летит прекрасно, без особых проблем, всё хорошо. Вот про другие языки сказать не могу. Могу лишь сказать, что вот я говорил про три курса, да, Java C# Sharp GL на DDD. И при этом есть ребята, которые, ну, на других языках программируют. Они задают вопросы: "А могу ли я прийти на другом языке и сделать всё то, что вы делаете?" Я говорю: "Слушай, теория везде одинаковая. как бы в Африке теория, как бы если ты синтаксис условно понимаешь там любого из этих трёх языков и сможешь его замапить на свой язык, то нет проблем, как бы. И к чему я это говорю, что на сегодняшний день приходили ребята на тайпскрипте и сделали, ну, то есть те ребята, которые прошли до конца курс ДД, сделали все, имплементировали все паттерны, как ДД, так чисто архитектура. Я и перечисли языки. Это Typescript, C++, Cotlн, PHP, Python. Ну, вроде бы всё. Вот вот на всех вот этих языках полностью ребята проходили всю программу и имплементировали все паттерны DDD. Вот. И у них никаких проблем не было. Были нюансы. Вот. Но со всеми нюансами можно справиться. А за другие языки не захожу. Вот на этих на этих опыт такой был вот не у меня, у у ребят. Вот. И никто из них там не плевался, не кидался. Все вполне смогли это реализовать. Ну я по секрету скажу, что разницы никакой не будет. Э, бери любые функциональные языки, всё то же самое. Тут это вообще к языкам не относится. Скорее, знаешь, просто хотел сказать, что, а, вот это восприятие из серии, если у тебя есть классы, у тебя есть объекты, а нет классов, нет объектов, и значит ты типа вообще не сможешь там думать в терминах сущностей, да, связи их и так далее. Это какой-то какой-то, не знаю, тёмные века, какое-то заблуждение страшное, которое есть часто у людей, которые пишут только на вот языках с классами. И я просто периодически напоминаю, что это вообще не так. То есть у тебя вон GOP тоже методы же не объединены с структурами в одной си, ну прямо в одной сущности. То есть это вообще-то не обязательная вещь, которая просто вот в каких-то языках есть, в каких-то нет. А по сути идейно у тебя многие вещи очень похожи. А второй вопрос давай так вот мы про это сказали. Я бы хотел всё-таки один кейс разобрать, а одну конкретную прикладную штуку, которая реально довольно важная и довольно сильно влияет, и она всем очень полезна на архитектурном уровне. Это доменные события. Угу. То есть даже тут неважно, ДД ты используешь или нет. Я тебе просто как пример могу сказать, и ты, наверное сам знаешь, у тебя во многих фреймворках это тупо внедрено в сам фреймворк как часть системы. Вот на PHP ты пишешь, да, берёшь, у тебя там это просто есть. Там никто не говорит слово ДД. Ты просто понимаешь, что, например, я зарегался, я могу там события бросить, в другом месте его поймать, среагировать. И люди пишут и как бы не понимают, что это вот вот это какая-то такая архитектурная штука. Могут не понимать. А поэтому я бы вот этот паттер разобрал прямо конкретно, чтобы был кейс, который мы с тобой описываем. То есть типа знаешь, в каком порядке? Как пишут обычно, если их нет, к чему это приводит и в какой момент это появляется и к чему это приводит, когда оно появляется. Вот сможем так сейчас с тобой? Ну да, сможем. Так, ну про доменные события. С чего начнём? Ну вот в целом, то есть человек пишет, он не знает ничего про доменные события, он просто пишет код, вот у него сервис, вот у него там регистрация, оплата, всё, что угодно. Какими проблемами он сталкивается и как доменные события их помогают решить. Угу. Так, ну о'кей. Про доменные события, да, давай так поговорим, что, во-первых, это дополнительный паттерн, который появился чуть позже, да, то есть он там было изначально несколько, четыре, по-моему, паттерна, потом появился доменное событие спустя время. Вот. То есть он такой приобретённый. Вот. Э-э, и в целом, да, если мы имплементируем, да, приложение там в DDD стиле, да, и у вас нет домена событий, то как бы и не проблема, да, то есть, э, это, скажем так, вишенка на торте, без которой можно жить. Вот, то есть она вам это надо только вот когда возникает какая-то конкретная ситуация, когда вы понимаете, что это более изящно решит проблему. Поэтому можно работать без них в обычном синхронном режиме, и у вас всё будет прекрасно, да, у вас будет работать доменная модель, агрегаты, велобжекты, всё будет складываться. Вот когда доменное события хорошо работает, да? То есть на сегодняшний момент мы все так или иначе строим, опять же таки скажу прораплённая система, да, где у нас есть разные сервисы, которые как-то с друг другом коммуницируют, да, и мы отправляем сообщение там, к примеру, в Кавку, чтобы другой сервис его считал. И как это зачастую происходит, да, у разработчика, который в DDD как бы не не варится, да, не знает, ну, не знает данную практику, он просто, видимо, где-то в конце юзкейса, когда мы весь сценарий завершаем, он просто берёт и там кавка с и туда в кавку что-то отправляет. Да, почему? Ну, потому что сценарий завершился на нам сказали по бизнесу, что в конце надо отправить. А как это сделает разработчик, который пишет в Dдd стиле? он, э, подумает: "Так, о'кей, хорошо, если мне нужно с другим сервисом поделиться чем-то, да, то что стало причиной этого события, да? А причиной в приложении, в котором есть доменная сущность, что может стать причиной, что какая-то доменная сущность поменяла своё состояние. Допустим, у меня был, э, заказ, да, корзина, к примеру, да, и в итоге она стала оформлена. И раз она стала оформлена, значит, у меня возникло прецедент, что у меня сформировалось доменное событие Basket Confmed, да? То есть она была оформлена и соответственно что в него вложилась вся та информация, которая этот эта сущность готова поделиться с внешним миром, да? То есть э чувствуете, да, разницу? В первом случае мы просто в консеускейсе сделали, потому что сделали, а в данном случае мы продили доменное событие только вследствие изменения доменной сущности. Она стала триггером для этого доменного события. Потом мы его заворачиваем уже в интеграционно и публикуем уже в очередь для другого сервиса, да? То есть в концепт DDD всё событийное взаимодействие идёт от от доменных сущностей, что каждый метод доменной сущности, который её меняет, он потенциально может приводить к доменному событию, да, там заказ отменён, заказ создан, заказ оформлен, юзер заблокирован, да, то есть каждый метод, допустим, там blocked, create, он приводит, может приводить к доменному событию. И потом мы можем этим доменным событием делиться, э, как с другими приложениями, так и со своим собственным. Вот, э, это вот с точки зрения самой концепции. Вот в чём отличие от обычного отправки какого-то события куда-либо другим способом, что идёт всё от домена. Вот второй момент. А чем это лучше, чем если вот мы, допустим, в юскейсе начнём просто их явно отправлять? тем, что CAS начинает знать не просто про свой сценарий, да, он начинает уже думать и про то, что другой куда-то там что-то надо отправить, хотя это в целом не его задача. Его задача поменять состояние нашего приложения, а не куда-то что-то отправлять. Вот. И тестировать этот кейс становится сложнее. В нём появляется дополнительные лови, которые там могло не быть. Вот. И в итоге он распухает. Вот с доменными событиями у нас кейс завершается только тем, что мы какую-то сущность изменили и сохранили в репозитории. А доменное событие уже вылетело, вылетело фоном вследствие сохранения сущности в репозитории. Вот. И таким образом мы реакцию на события можем тестировать отдельно, выбор событий можем тестировать отдельно, изменение агрегата можем тестировать отдельно, лист можем тестировать отдельно. То есть у нас появляется вот та самая фишка, да, что у нас, э, хорошо структурированное приложение можно тестировать атомарно каждую его часть. Вот. И в итоге получается дешевле и быстрее. Вот. Не знаю, что ещё про доменные события добавить. Добавлю, потому что есть ещё несколько важных моментов. Первый, наверное, момент, в принципе, дублирование. То есть когда у тебя сценариев реально много, у тебя отправка этих событий начинается просто тупо везде. То есть ты как бы в кавку тут пошёл, тут пошёл, тут пошёл, тут пошёл. Кстати, я ещё хочу сказать, что это не обязательная история про вообще асинхронную обработку. То есть, например, а у нас внутри у нас монолит, да? При этом, опять же, современный монолит - это что? Это значит, что ты ещё коммуницируешь с 500 внешними сервисами. у тебя там от 1s до helpстемы AMRM, да? Или я уж не говорю про маркетинговые, то есть, например, отправка в в BI в бийку какую-нибудь систему аналитики, у тебя вообще все доменные события туда улетают. То есть любой человек, который хочет строить воронки, смотреть, как люди учатся, ну там в зависит от того, какой у вас бизнес, вам нужны события. Поэтому практически все наши сервисные истории, они заканчиваются каким-то отправкой. Либо это а email, либо внешняя аналитика, либо это вообще что-то внутри у нас происходит и так далее. Поэтому это на любом уровне проявляется в огромном количестве. То есть это инфраструктурный код, и код логики как бы тоже. То есть мы таким образом, во-первых, убираем огромное количество дублирования, а во-вторых, это у тебя сегодня только кавка, а завтра ты хочешь это отправить в AMCRM, в кликхаус и ещё в пять систем. И каждый раз тебе будет надо ходить во все эти места, искать, где это используется, и добавлять туда всю эту штуку как прослойку. И в этом смысле доменные события - это очень прекрасная вещь, потому что у тебя как бы классический обсервер, да, то есть ты расставил событийную генерацию события и в одном месте описал просто обработчиков, которые они могут подписываться на это событие большим количеством. И что это ещё даёт? Во-первых, очень часто, например, такие системы автоматом позволяют, а, включить асинхронную обработку. Типа, например, вот это событие асинхронно обрабатывай, а вот это асинхронно, и он у тебя в бэкграунде, например, будет работать. Это фреймворки уже дают. Второе, у тебя уходит дублирование. И в-третьих, как ты сказал по поводу тестирования, я тут хотел уточнить, у тебя вместо моков ты можешь просто тупо в тесте выключить, сказать: "Не вызывать доменные события". Ну, в смысле, триггеры. И таким образом тебе не надо мокать дополнительно. Вот ты просто можешь это выключить. И, наверное, последнее, что хотел сказать, а, есть не, ну, как бы любое хорошее инженерное решение, оно всегда компромисс. То есть с одной стороны мы вот эти плюсы, они все объективные, но вообще-то есть кое-какой косячок. У тебя система, как ни крути, становится чуть-чуть менее явная. То есть ты понимаешь, что событие произошло, а хрен знает, что там отреагировало. То есть типерь не можешь просто просмотреть код и увидеть всё, что происходит. У тебя появляются вот эти вот событийные связи, которые всегда требуют чуть большей ментальной как бы нагрузки. Но на масштабе, когда у тебя чем больше становится, тем больше оно начинает играть в плюс. Хотя и да, ты такой иногда: "Так, что за фигня произошла? А там, наверное, реакция на события. Пошёл смотреть, и там у тебя ещё 500 обработчиков. А если там появляются зависимые, вот тогда начинается задница. Поэтому этот паттерн при том, что он хорош, надо всегда понимать и границы, и к чему может привести необузданное как бы использованиние и так далее. Но в целом это круто. То есть совсем его игнорировать нельзя, иначе будет очень много вот этого кода, я бы сказал, инфраструктурного, да, который всё это добро делает. Угу. Ну, здесь единственное, я бы отделял бы интеграционное события от доменных событий. Вот потому что мы, ну, как бы как будто про то и про другое как про одно сказали. То есть, когда мы говорим про там со всеми системами, да, которые ты перечислил, да, события туда улетают. Это интеграционные события, они к доменам как бы имеют косвенное отношение. Ну, у тебя в системе всё равно так будет реализовано. То есть, например, у тебя происходит выкидывание события зарегистрированный пользователь. Чтобы ты понимал, мы у себя в систем 10 отправляем, что пользователь зарегистрирован, и их можно подключать в любой момент в любом количестве. Да. Вот половина из них аналитически. Вот смотри, какая история. Ты меняешь какую-то сущность, ну, допустим, пользователь есть, да, у тебя естькейс создать юзера, да? Во-первых, у тебя в юзкейсе, да, в конце не идёт там кавка или там event, да, мы же могли бы сделать event, а потом в хендлере просто обрабатывать и отправлять в 10 систем. Могли же так сделать в CAS? Ну, могли бы. Вот. Но вот здесь в основном отличие доменного события именно в другом, что у тебя в useкейсе нет никакого send. У тебя там есть агрегат сейф. И когда он делает, это очень сильно от фреймворка зависит. Кстати, тут знаешь, наверное, что хочется сказать, это реально, а я ещё встре мы совершенно про это забыли. А многие как раз говорят о том, что, ребята, мне придётся, я это называю писать против ветра. То есть у меня есть фреймворк, он работает определённым образом, а мне тут, значит, надо всё переписывать. И помнишь, я говорил во многих системах, ну, например, вот мы на Rails пишем, да, у нас вот эта событийная система такого уровня, она не встроена. То есть у тебя не про сохранение агрегата это происходит. Мне кажется, что здесь фреймворк вообще не имеет никакого значения. На самом деле, вот у меня, а, вот есть три кейса, да, во всех трёх кейсах это делает нефреймворк. То есть это обычная папсабка, папса, который может реализовать любой разработчик как бы внутри приложения. Ну я скорее к тому, что ты просто сказал, что это на уровне сейва работает. Вот, например, у меня на уровне сейва а этого нет, но зато есть отдельная система, которая прямо во фреймворке отдельным пакетом идёт, и ты, грубо говоря, сейв там можешь делать, сколько влезет, это твоя история. Но ты после сейва ещё прямо явно там прямо типа оно так примерно и называется, типа сгенерировать событие, что он зарегался, и ты туда скорее просто отда отдаёшь этого пользователя. То есть по факту у тебя, ну, тут вопрос нет ли там проблемы с транзакционностью, что ты сначала его сохранил, а потом отправляешь и вдруг оно не отправится. Вот и что тогда будет? Юзер поменял своё состояние, а сообщение не ушло. Вот поэтому тут нюансы есть. Есть нюансы, да. Ну там это отдельно можно проговаривать. Я просто к тому, что вот бывает, что у тебя система это реализована, она может там называться как-то по-другому, но она есть. Ну, в общем, и таких паттернов много, правильно, ведь таких паттернов много. Просто к чему? К тому, что почему нужно это изучать? Почему стоит про это копать? А то все такие вот микросервисные паттерны, но вообще-то кроме них есть ещё и куча таких паттернов, которые даже если вам кажется, что вы не изучаете ДД, что вы вам не нужно ДДД, на самом деле это очень прикольные штуки с точки зрения того, как организовывать логику, разбивать её по слоям и строить границы. На мой взгляд, на сегодняшний день, как бы, если говорить про микросервисные паттерны, на сегодняшний день, ну, все крупные компании, они уже сделали шаблоны микросервисов, да, какой-то некогою там пас, что-то в этом роде, где ты просто сделал там кры создался, да, и он там поехал. Вопрос насколько они правильно это сделали, неправильно, но в целом там зачастую правильно всё. Вот. А, а вот когда разработчик начинает этот сервис набивать логикой, вот тут как бы эти ребята платформе говорят: "Ну, как бы мы тебе шаблон дали, а ты дальше там сам внутри уже давай". Угу. И вот я на личном опыте, да, просматривая разные репозитории, там, делая разные аудиты, я столкнулся именно с тем, что как бы глобально э сервис работает, там в Кавку отправляется Outbox, inbox всё там у них circleбреaker, всё замечательно. Ну, серединка вот эта как бы это как, знаешь, вот прям спагет код, короче, всё в кучу. Вот. И в итоге, да, в итоге всё равно ребята страдают, да. Вот как тот кейс я тебе сказал, что ребята сделали с через сейд пришли, сказали, что он у них legгаси. Вот. То есть на сегодняшний день, мне кажется, нужно фокусироваться именно на навыках построения архитектуры внутри микросервиса современному разработчику. Потому что раньше, когда монолиты мы разрабатывали, всё было очень просто, да? Ты приходишь в компанию, и там есть синер там разработчик, он этот молит как бы там вылезал за 5 лет, и он тебе просто говорит: "Слушай, делай просто вот вот как я, короче, повторяй просто вот новую фичу, то делай такой слой, такой слой, такой слой, всё, туда добавил, всё, поехали". И все просто берут и какие-то набор паттернов просто, ну, копипастят и имплементируют новые фичи. Ну, по образу подобия. Когда же мы сейчас делаем новый микросервис, да, и команды его, мы по сути каждый раз решаем архитектурные задачи. Мы запускаем эти сервисы условно там, ну, минимум раз в год, да, и каждый год у нас встаёт вопрос: а как мне внутри архитектурно реализовать? Поэтому, если раньше в анолитах не было такого фокуса, да, на этих навыках и компетенциях, то на сегодняшний день, если разработчик там знает язык, да, но не может нормально структурировать приложение, чтобы оно было удобно в поддержке, легко тестируем, чтобы могли легко заменять технологии, менять домен, если бизнес поменялся, и не говорить бизнесу, что ой, мы тут как бы э всё реализовали, теперь нам поменять это сложно и нужно 3 недели, да, чтобы вот этого всего не было, нужно уметь домен делать по DDD, а всё остальное приложение делать в стиле чисто. архитектура. И здесь от языка, вот, как мы выяснили, это особо не зависит, да, большая тройка вообще без проблем. C#ARP, Java, GLang, а другие языки, э, тоже тоже есть скажем так, имплементация на PHP, на Пайthне, ребята тоже делают, это всё тоже работает. Вот поэтому вот на сегодняшний день, на мой взгляд, это такой вот навык разработчик, который хочет из медла перейти в синьора. Ну что ж, я думаю, что мы неплохо с тобой сегодня эту тему разобрали. А-а, ребят, напишите, пожалуйста, кого убедили, кого не убедили. Кто-нибудь обязательно скажет, что мы всё с тобой неправильно поняли. Или конкретно я, или конкретно ты. Это это всегда так бывает. Так что мы к этому готовы. В общем, ребят, э расскажите, что вы об этом думаете. Стоит ли, кстати, сделать отдельное видео уже по конкретике, потому что мы старались сегодня всё-таки про смысловую часть, про философию, про применимость и чуть-чуть про конкретику. Но я так понимаю, Кирилл, что если мы начнём перечислять а и агрегаты, и обжекты и так далее, у нас там репозиторий хватит ещё материала, да, чтобы рассказывать. Но это очень прикладная вещь, да, конкрет она, конечно, более такая фактурная, более конкретная, с конкретными, скажем так, целями, плюсами, ощутимыми для разработчика. Вот. Да, там в целом ещё на один подкаст наберётся. Про эту часть, ну, даже на самом деле очень интересно поговорить. Я бы, мне кажется, кстати, ээ, вот периодически я делаю лайвы, и лайвы классно заходят. Возможно, эта часть стоит прямо лайвом сделать, взять какую-то область и попробовать её разложить и покодить. Я, скорее всего, такое уже делали, но я думаю, что имеет смысл повторить. Имеет смысл повторить, да. Ребят, всем большое спасибо. Если вам понравилось, ставьте лайк, подписывайтесь. Приходите Кириллу на его курсы. Если не понравилось, ставьте дислайк и пишите, что ДД [ __ ] и что вы об этом думаете. Тоже нормально. Всем спасибо. Пока. Ну, всем пока.

[музыка]