Re[40]: Как внедряли DDD в Яндекс 360. - Архитектура программного обеспечения

Здравствуйте, gandjustas, Вы писали:

S>>>>Ну тактические все-таки что-то новое, все эти agg root, transaction script, entity, values. А так да, взяли отовсюду понемногу.
G>Абсолютно не связанные между собой вещи. Микросервисы ничего не говорят об архитектуре внутри сервиса.

Тактические и стратегические да, не связаны. Зачем-то их убрали под один зонтик ДДД. На счет арх-ры
микросервисов -- ну приставка микро должна говорить о том, что все-таки желательно иметь что-то простое.
Т.е. в идеале микросервис должен говорить об очень простой архитектуре.

S>>Ну а Эванс добавил стратегические паттерны и превратил все это методологию. Что называется стоял на плечах гигантов.
G>Как я и написал ниже он добавил философию.

1)Это, кстати, важно. Кроме шуток. Философия вещь важая и нужная.
2)Все-таки он превратил все это дело в методологию.

S>>Соглашусь. Ну, кстати, и ООП тоже своего рода мода.
G>На ооп мода была в середине девяностых — середине нулевых. Мода прям адская, все что не ООП — было "фу". На волне этой моды ДДД и появилось.
G>Потом микрософт нанял Эрика Мейера, который до этого Хаскелем занимался и он всех покусал функциональщиной, а в 2011 вышел стандарт с++11, в ктором вся стандартная библиотека была функциональной.
G>На той волне даже JS голову поднял, в нем давно было то, что в мире ФП ценилось.

Да, помню эти времена и по срачам в жж и тут. Машинное обучение все это снесло или сделало мало релевантным.
Народ перенес свой фокус туда.

S>>Странно, учитывая что он на 20 лет появился раньше. А на питон почему не смотрели, вроде для него уже были фреймоврки для веба?
G>Возраст языка не показатель популярности. в 2005 на полках книг по C# и Java было одинаково, даже по C++ было меньше, хотя он старше. А по перлу если одна попадалась на полке, то лежала там несколько лет.

В библио-глобусе до фига была книг по любой технологии, бывал там в 2005-2010 очень и очень часто.
Но это в Москве. Хотя думаю, и в любом крупном областном центре были свои хорошие книжные.

S>>При чем здеьс обеспечение инварианта и ДДД?
G>Видимо это никак не связанные вещи

Видимо.

S>>Объектами самой бд, типа строки\колонки\талбицы и т.п.
G>У слова "объект" в программировании есть вполне конкретное значение. строки\колонки\талбицы не являются объектами с точки зрения работы с БД.

С тз реализации вполне являются.

S>>Я пытаюсь настоять на его полезности хотя бы в рамках распила монолита на микросервисы.
G>Ок, давай примеры чем именно ДДД помогает. А еще было бы неплохо описать "механизм действия", а то может ДДД не при чем.
G>Или нам поверить что помогает потому что кто-то сказал?

Берете монолит, находите в нем домены, в доменах BC и по этим BC микросервисы и нарезаете. Желательно чтобы
1 BC — 1 agg. root. Но это, кажется, не обязательно.

G>>>Бремя доказательство обычно возлагается на того кто утверждает, пока он не представил объективные аргументы.
S>>У меня их нету
G>Ок, значит просто вера

Как и в эффективность ООП, получается.

S>>Давайте разберем контрпример. Хотя думаю, что мое утверждение выше было чрезмерно сильным. Возможно ДДД ничего такого не утверждает.
G>Допустим разрабатывается система, аля трекер. Заказчик хочет возможность ограничить количество задач для пользователя.
G>Будут две сущности: Issue и User, связанные много-к-одному.
G>У Issue есть метод AssignTo, которому надо передать User или его Id, чтобы связать. И надо как-то гарантировать что выполняется условие, что для одного User назначено не более трех Issue/

G>Какую реализацию нам диктует прагматичный подход (ПП):
G>Прямо в контроллере, в одной транзакции (!) сделать два запроса:
G>

G>update issues set user_id = @userid where id = @id;
G>select count(*)from issues where user_id = @userid
G>

G>Для PG и других баз с оптимистичными блокировками нужен уровень изоляции serializable и повтор запросов при ошибке, а для SQL Server без RCS и MySQL (и других блокировочников) достаточно read committed

G>Реализация на C# для postgres может выглядеть так:
G>

G>var db = ctx.Database;
G>await db.CreateExecutionStrategy().ExecuteAsync(async ct =>
G>{
G>    await using var t = await db.BeginTransactionAsync(System.Data.IsolationLevel.Serializable, ct);
G>    await ctx.Issues.Where(i => i.Id == id).ExecuteUpdateAsync(s => s.SetProperty(x => x.UserId, userId), ct); 
G>    if (await ctx.Issues.CountAsync(x => x.UserId == userId, ct) > 3) throw new Exception("Auchtung");
G>}, ct);
G>

Для MVP сойдет, а для какого-нибудь аналога джиры такое себе.

G>С этой же задачей я пошел в рекомендованный тобой чат, попросил показать пример DDD. три дня срачей, рассказов что я не умею требования анализировать, что задача вообще нереальная и не надо её решать итд.
G>Самое лучшее что один из участников написал пайтоне
G>

G>class User(DomainEntity[UserId]):
G>    def __init__(self, entity_id: UserId, issue_count: int) -> None:
G>        super().__init__(entity_id)
G>        self._issue_count = issue_count

G>    def take_issue(self) -> None:
G>        MAX_ISSUE_COUNT = 3
G>        self._issue_count += 1
G>        if self._issue_count > MAX_ISSUE_COUNT:
G>            raise TooManyIssues


G>class Issue(DomainEntity[IssueId]):
G>    def __init__(self, entity_id: IssueId, metadata: str, user_id: UserId | None):
G>        super().__init__(entity_id)
G>        self._metadata = metadata
G>        self._user_id = user_id

G>    def assign_to(self, user: User) -> None:
G>        if self._user_id:
G>            raise IssueIsAlreadyAssigned

G>        user.take_issue()
G>        self._user_id = user.entity_id

G>

G>То есть прделагают два агрегата. User хранит счетчик issue. Причем в реальности такая логика будет размазана по разным файлам.
G>1) Во первых код тупо не полный, так как кроме увеличения при назначении надо еще уменьшать при переназначении.
G>2) Как будет обеспечиваться изоляция транзакций непонятно, этого кода также нет.

G>А теперь представим что программа у нас развивается и требования чуть усложнились: теперь надо считать не все Issue, а только в нужном статусе.
G>В варианте на C# добавить фильтр и код проверки вызывать как в методе назначения задачи, так и при смене статуса на нужный.
G>Что делать в варианте на пайтоне — даже боюсь представить.

G>Получается что сделали по ДДД максимально хорошо насколько люди поняли ДДД, а получилось раздутое нерасширяемое и скорее всего ненадежное говно.

Нерасширяемое оно получилось как раз на С# -- начните получать певрые пожелания и доработки от заказчиков, а играться
со статусами и привет. На питоне как-то солиднее решение, да делать дольше и сложнее, но надолгосрок будет проще.

S>>Блин, ну как тогда любая технология взлетает, если в нее по сути по началу верять пару человек, если вообще не один? При таком подходе никакого ООП бы не было.
G>Серьезно считаешь что ООП родилось из веры?
G>ООП родилось из решения частных задач, а именно моделирования поведения в агентной системе. Внезапно первый ОО-язык это была в первую очередь агентная система.
G>Авторы ООП никуда ООП не продвигали. Последователи сами захотели включить его в свои языки, причем сильно по разному.
G>От появления ООП до первых популярных языков прошло почти 20 лет.
G>Больше всех ООП популяризировал C++, потому что он по сути добавлял новые фичи в адски популярный тогда С. Возможно если бы не Страуструп то такого хайпа и не случилось бы.
G>Популярность ООП это скорее череда совпадений и неплохой изначальной идем, которую специально никто не форсил.

А откуда была уверенность в неплохой изначальной идеи? Т.е. это был прагматичный расчет? А куда девать тогда
череду совпадений?

G>А с DDD ровно обратная картина.

Блин, кучу всего объединил под один зонтик (см. выше) и попытались приделать какую-то методологию.
Что там обратного -- не понятно.

G>>>Насчет solid не знаю, про agile и рефакторинг находил.
S>>Ну вот про научно доказанную пользу agile я бы почитал.
G>Да там банальное исследование было: опрос какие практики применяют и считали корреляцию с "успешностью" проектов. Как успешность считали уже не помню.

Я так и думал -- correlation doesn't imply causation. (с) Т.е. никакого научного обоснования, а такая же веря как с ДДД.

Здравствуйте, Sinclair, Вы писали:

S>>Какие, например?
S>Банальные вопросы вроде "зарезервировать товары заказа на складе".
S>Потому что в домене есть складские остатки, есть товары, есть заказы. Ни в кого из них запихать метод "зарезервируй" не получается без того, чтобы втащить внутрь этого метода не-доменную логику.
S>А делать специальный AggregationRoot, который типа и должен всё это делать, противоречит самой идее Ubuquitous Language, т.к. этого рута в "домене" не существует.

Это странно, почему так нельзя делать? А как тогда машину описать, ведь ее не существует, а существуют колеса,
кузов, двигателя, трансмиссия, ходовая часть и т.п. Но очевидно в соотв. домене будет что-то типа Car или Automobile и т.п.
именования.

Здравствуйте, Sharov, Вы писали:

S>На питоне как-то солиднее решение, да делать дольше и сложнее, но надолгосрок будет проще.
Эт, в принципе, резюмирует всю дискуссию.
С такой точкой зрения идеальный код для 2*2 будет new MultiplierFactory.get_default_multiplier().set_first(a).set_second(b).execute().get_result(); Он гораздо солиднее.

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

Здравствуйте, Sharov, Вы писали:

S>Я так и думал -- correlation doesn't imply causation. (с) Т.е. никакого научного обоснования, а такая же веря как с ДДД.

Это называется "когортные исследования". В пирамиде медицинских доказательств они например занимают третье место. Второе за рандомизированными плацебо-контролируемыми исследованиями, а первое — мета-анализы. Когда провести рандомизированный эксперимент невозможно, то когортные исследования признаются достаточно хрошим источником доказательств.

Напомню что про DDD вообще нет ни одного исследования, которое хоть какие-то измеримые результаты дает. Там все "доказательства" это просто мнения людей. Причем изначально довольно небольшой группы. Сейчас люди часто приводят пример из книги Эванса (которой уже 20+лет), а когда доходит до примеров реалистичных и актуальных — уже не так хорошо даже на них ДДД работает.

Так что вера ДДД гораздо сильнее, чем вера в ООП или agile.

Здравствуйте, gandjustas, Вы писали:

S>>Я так и думал -- correlation doesn't imply causation. (с) Т.е. никакого научного обоснования, а такая же веря как с ДДД.
G>Это называется "когортные исследования". В пирамиде медицинских доказательств они например занимают третье место. Второе за рандомизированными плацебо-контролируемыми исследованиями, а первое — мета-анализы. Когда провести рандомизированный эксперимент невозможно, то когортные исследования признаются достаточно хрошим источником доказательств.
G>Напомню что про DDD вообще нет ни одного исследования, которое хоть какие-то измеримые результаты дает. Там все "доказательства" это просто мнения людей. Причем изначально довольно небольшой группы. Сейчас люди часто приводят пример из книги Эванса (которой уже 20+лет), а когда доходит до примеров реалистичных и актуальных — уже не так хорошо даже на них ДДД работает.

Согласен, но все равно это так себе исследования. Будем тут честны.

G>Так что вера ДДД гораздо сильнее, чем вера в ООП или agile.

Спорить не буду.

Здравствуйте, gandjustas, Вы писали:

S>>На питоне как-то солиднее решение, да делать дольше и сложнее, но надолгосрок будет проще.
G>Эт, в принципе, резюмирует всю дискуссию.
G>С такой точкой зрения идеальный код для 2*2 будет new MultiplierFactory.get_default_multiplier().set_first(a).set_second(b).execute().get_result(); Он гораздо солиднее.

Речь про долгосрок, про подстелить себе салому, а не дурака валять с ООП. Все-таки на долгий срок
если выбирать, то питон решение выглядит солиднее, чем sql скрипт + обвязка на C#. Во втором случае скорее
всего во что-то упретесь и придется переписывать с нуля, а в первом добавить немного кода.

G>Напомню для остальных читателей темы, что нет ни одного свидетельства о том, что более длинный код будет "проще на долгосрок". Множество свидетельств обратного.
G>Но вера в "солидность" непоколебима и видимо никакие разумные аргументы не могут её разрушить.

Также напомню читателям, что моделировать модель предметную область гораздо лучше, чем обновлять соотв. строки в бд.
Да, дольше и сложнее, но на долгосрок самое то.

Здравствуйте, Sharov, Вы писали:

S>Также напомню читателям, что моделировать модель предметную область гораздо лучше, чем обновлять соотв. строки в бд.
Для этого утверждения нет никаких доказательств.

Здравствуйте, Sharov, Вы писали:

S>Это странно, почему так нельзя делать? А как тогда машину описать, ведь ее не существует, а существуют колеса,
S>кузов, двигателя, трансмиссия, ходовая часть и т.п. Но очевидно в соотв. домене будет что-то типа Car или Automobile и т.п.
S>именования.
Вот такие примеры — вредны. Они не решают реальную проблему, и иллюстрируют удобство написания кода, который вообще не надо писать.
Точно так же, как примеры про наследование фигур. Я уже неоднократно говорил — ни в одной системе вам не потребуется наследовать фигуры друг от друга; скорее всего, единственная фигура, которая вам потребуется — это PolyLine. А наследования с полиморфизмами появятся там, где вы будете этот Polyline обрабатывать — ну там, растеризовать, или превращать в SVG, или в метафайл.
Так и с автомобилем — скорее всего, у вас не будет полиморфного объекта "Car" с объектами, из которых она состоит.
Будет, скорее всего, какой-то объект типа ComplexAssembly, с умением "состоять из".
При этом никакого поведения, кроме "состоять из", у него не будет. Всё остальное будет делать какая-то внешняя по отношению к нему логика — собирать, учитывать, регистрировать, отгружать заказчику и т.п.

Здравствуйте, Sharov, Вы писали:

S>Речь про долгосрок, про подстелить себе салому, а не дурака валять с ООП. Все-таки на долгий срок
S>если выбирать, то питон решение выглядит солиднее, чем sql скрипт + обвязка на C#. Во втором случае скорее
S>всего во что-то упретесь и придется переписывать с нуля, а в первом добавить немного кода.

Скорее всего наоборот: в питоновом решении упрётость наступит примерно сразу, и придётся переписывать всё это нагромождение паттернов друг на друга.
А в С# кода мало, даже если его придётся целиком переписать — не жалко. Да и переписывать-то скорее всего не придётся — учёт статусов и чего угодно делается добавлением предикатов к запросу.
Как только предикаты становятся сложными и начинают использоваться в нескольких местах — код уезжает из каждого конкретного запроса в функцию, которой пользуются все:

var db = ctx.Database;
await db.CreateExecutionStrategy().ExecuteAsync(async ct =>
{
    await using var t = await db.BeginTransactionAsync(System.Data.IsolationLevel.Serializable, ct);
    await ctx.Issues.Where(i => i.Id == id).ExecuteUpdateAsync(s => s.SetProperty(x => x.UserId, userId), ct);
    if (await ctx.СountUserIssues(userId, ct) > await ctx.GetMaxUserIssues(userId)) throw new Exception("Auchtung");
}, ct);

S>Также напомню читателям, что моделировать модель предметную область гораздо лучше, чем обновлять соотв. строки в бд.
Вопрос не в том, моделировать ли. Вопрос — в том, как моделировать.
Тот самый Липперт же не предлагает отказаться от программирования D&D. Он предлагает другую модель, которая, в отличие от наивного подхода с new Warrior(), работает.
S>Да, дольше и сложнее, но на долгосрок самое то.
Нет.

Здравствуйте, gandjustas, Вы писали:

G>Можно подробнее по конкретный кейс, какие запросы к базе были и на что переехали в итоге?

Была задача получать и обрабатывать документы из Postgres. Сделали ее максимально просто: никаких репозиториев, в сервисный слой сразу инжектировался DbContext. Потом приходит задача, что нужно обрабатывать аналогичные документы из Oracle, в котором совершенно другая схема. То есть меняется только способ получения данных, поэтому вполне нормально в такой ситуации выделить из сервисного слоя отдельный сервис для работы с данными и назвать его DocumentsRepository, разделить его на интерфейс, который будет использоваться в сервисном слое, и две реализации, которые будут согласовывать внешние данные с данными приложения. В итоге приложение работает с IDoсumentsRepository, в котором методы GetActualDocuments, GetDocumentsForSign, GetDocumentStreamById и т.д., а все зависимости от конкретных провайдеров и схем лежат в отдельных подпроектах и в бизнес коде никак не участвуют.

Здравствуйте, gandjustas, Вы писали:

G>>>По СУБД можно искать произвольным запросом, а по условному веб-сервису не всегда.
G>>>Если ты в своей программе ориентируешься на метод например GetOrdersByUser, а веб-сервис возвращает только по id, то ты никогда не заменишь базу на веб-сервис.

A>>А как задача GetOrdersByUser для такого веб-сервиса будет решаться без репозитория?
G>Она вообще никак решаться не будет, в этом и проблема. Если ты для реализации требований опирался на такую операцию, то ты никогда ни на какие внешние сервисы не переедешь.
G>Чтобы была возможность такого переезда у тебя должны быть или очень простые задачи по работе с состоянием, которые сводятся к взять\положить по ключу, или внешний сервис не такой уж внешний, а дорабатывается по вашим требованиям и фактически в него протекают части логики.

Тогда о чем разговор? Задача нерешаема, что с репозиторием, что без.

Здравствуйте, amironov79, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Можно подробнее по конкретный кейс, какие запросы к базе были и на что переехали в итоге?

A>Была задача получать и обрабатывать документы из Postgres. Сделали ее максимально просто: никаких репозиториев, в сервисный слой сразу инжектировался DbContext. Потом приходит задача, что нужно обрабатывать аналогичные документы из Oracle, в котором совершенно другая схема.
Вы же говорили что использовали внешний сервис, который вообще не РСУБД. Или я что-то не понял?

A>То есть меняется только способ получения данных, поэтому вполне нормально в такой ситуации выделить из сервисного слоя отдельный сервис для работы с данными и назвать его DocumentsRepository, разделить его на интерфейс, который будет использоваться в сервисном слое, и две реализации, которые будут согласовывать внешние данные с данными приложения. В итоге приложение работает с IDoсumentsRepository, в котором методы GetActualDocuments, GetDocumentsForSign, GetDocumentStreamById и т.д., а все зависимости от конкретных провайдеров и схем лежат в отдельных подпроектах и в бизнес коде никак не участвуют.

Использование двух баз с разными схемами и провайдерами в рамках EF решается просто, даже без класса репозитария
Простой способ:
1) Делаете один базовый абстрактный класс контекста со всеми свойствами и классами сущностей и два наследника, в каждом свою модель пилите под свой провайдер
2) Делаете ОДИН класс контекста, в котором модель переключаете так: https://learn.microsoft.com/en-us/ef/core/modeling/dynamic-model, и используете KeyedService для подстановки, но если вы заходите миграции, то придется еще отдельный код для этого написать.

Здравствуйте, amironov79, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>>>По СУБД можно искать произвольным запросом, а по условному веб-сервису не всегда.
G>>>>Если ты в своей программе ориентируешься на метод например GetOrdersByUser, а веб-сервис возвращает только по id, то ты никогда не заменишь базу на веб-сервис.

A>>>А как задача GetOrdersByUser для такого веб-сервиса будет решаться без репозитория?
G>>Она вообще никак решаться не будет, в этом и проблема. Если ты для реализации требований опирался на такую операцию, то ты никогда ни на какие внешние сервисы не переедешь.
G>>Чтобы была возможность такого переезда у тебя должны быть или очень простые задачи по работе с состоянием, которые сводятся к взять\положить по ключу, или внешний сервис не такой уж внешний, а дорабатывается по вашим требованиям и фактически в него протекают части логики.

A>Тогда о чем разговор? Задача нерешаема, что с репозиторием, что без.
Именно. Поэтому использование репозитария может "помочь" только при смене одной РСУБД на другую, а это прекрасно делается и без репозитария.

Здравствуйте, gandjustas, Вы писали:

G>Вы же говорили что использовали внешний сервис, который вообще не РСУБД. Или я что-то не понял?

Я говорил, что не не РСУБД, а в том числе и не РСУБД.

G>Использование двух баз с разными схемами и провайдерами в рамках EF решается просто, даже без класса репозитария
G>Простой способ:
G>1) Делаете один базовый абстрактный класс контекста со всеми свойствами и классами сущностей и два наследника, в каждом свою модель пилите под свой провайдер
G>2) Делаете ОДИН класс контекста, в котором модель переключаете так: https://learn.microsoft.com/en-us/ef/core/modeling/dynamic-model, и используете KeyedService для подстановки, но если вы заходите миграции, то придется еще отдельный код для этого написать.

Каша какая-то. Проще 2 отдельных контекста сделать.

Здравствуйте, amironov79, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Вы же говорили что использовали внешний сервис, который вообще не РСУБД. Или я что-то не понял?
A>Я говорил, что не не РСУБД, а в том числе и не РСУБД.
Я спрашивал про не РСУБД. Было такое на практике?

G>>Использование двух баз с разными схемами и провайдерами в рамках EF решается просто, даже без класса репозитария
G>>Простой способ:
G>>1) Делаете один базовый абстрактный класс контекста со всеми свойствами и классами сущностей и два наследника, в каждом свою модель пилите под свой провайдер
G>>2) Делаете ОДИН класс контекста, в котором модель переключаете так: https://learn.microsoft.com/en-us/ef/core/modeling/dynamic-model, и используете KeyedService для подстановки, но если вы заходите миграции, то придется еще отдельный код для этого написать.

A>Каша какая-то.
Это разные способы

2)Проще 2 отдельных контекста сделать.
Это п1

В обоих случаях вызывающий код будет прост ссылку на класс наследник DbContext принимать ссылку и работать с ним.

	От:	Sharov
	Дата:	31.01.26 20:55
	Оценка:

	От:	Sharov
	Дата:	31.01.26 20:58
	Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	31.01.26 21:04
Оценка:	+1

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	31.01.26 21:10
Оценка:	6 (1)

	От:	Sharov
	Дата:	31.01.26 22:29
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	01.02.26 02:12
Оценка: