Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Чем DDD хуже истоков agile и термина рефакторинг?
G>>Тем что рефакторинг и agile имеет доказанную пользу, а DDD — нет.
S>Для разработчика из видео выше это будет не так -- у него ДДД имеет доказанную пользу. Короче, это субъективщина.
Мне кажется ты не понимаешь суть слова "доказанную"...
S>>>>>Я работал в компании, которая распиливала монолит на микросервисы по ДДД. Использовали стратегические паттерны.
G>>>>Какие паттерны?
S>>>https://habr.com/ru/articles/787460/
G>>Это не про код, а про какую-то философию, тут вообще сложно что-либо оценивать. Меня именно код интересует.
G>>Ну вот мы сделали два разных класса Employee. У меня сразу вопрос: это одна таблица в системе или нет? Если
S>Это можно решить в самый последний момент, согласно ДДД. Это детали.
Так вот мы пришли к этому моменту. Это одна таблица или нет?
G>>Как быть если ЗА начинает зависеть от skills (они в разных моделях)?
G>>И вообще calculateWageWithoutTax в employee выглядит крайне сомнительно, для расчета ЗП и налогов нужно такое количество данных подтянуть из всей системы, из-за которых сама система и делает, что прокинуть это все в один Employee выглядит неразумным.
S>Значит нужен какой-то другой agg root.
Какой? Почему в этом примере именно Employee? Что этот пример должен был нам сказать?
Может нам наоборот стоит нарезать задачу контексты по другому? напрмиер на расчет зряплаты, грейдирование, итд. В каждом будут свои "root", а Employee как раз получится один для всех, так как он по сути просто справочник, который точно хранится в одной таблице.
Я тут не фантазирую, конфигурация 1С ЗУП так устроена. В 1С кстати заложена архитектура Event Sourcing и оптимизации темпоральных запросов (даже проверка остатков прекрасно решается), но в ней нет Domain Model (вернее эта модель полностью соответствует таблицам в БД) и Bounded Context (одна баз — один bounded context).
G>>DDD это набор паттернов, которые вроде как должны хорошо работать в каких-то сценарияхх, но на проверку они все плохо работают.
G>>В любой книге про DDD 80% это паттерны и 20% это какие-то философские вещи.
S>На мой взгляд, скорее это методология, а не набор готовых рецептов. По-отдельности применять можно, но сложно. Точнее уже разбили на стратегически и тактические паттерны.
Пробелма в том, что без "тактических паттернов" методология DDD настолько очевидна, что смысла нет в отдельном названии.
Она сводится к трем вещам:
1) Универсальный язык для общения с заказчиком. По сути это раздел "термины и определения" из ТЗ по любому стандарту
2) Разделение проблемы на области — то что везде называние "модулями" (термин из структурного программирования) или "подсистемами" (термин из системной инженерии). В книге вернона и последующих даже упоминается иерархния (вложенность) областей, также как модули и подсистемы могут иметь вложенность.
3) Ограниченные контексты — единицы разработки и\или единицы деплоя.
Еще недавно появился EventStorming — по сути обычные брейнштормы, если отвязать их от event sourcing.
Фактически ничего нового DDD не дает. Мы все это видели например в UML — диграммы компонентов это предметные области, а диаграммы развертывания, диаграммы юзкейсов, процессов и логической структуры.
G>>Функционал нужен пользователю. Пользователь нажимает кнопки, кнопки вызывают хэндлеры. Вызывать репозиторий из хэндлера? А где тогда DDD?
S>Значит тут и репозиторий особо не нужен, обычный DAL.
Так это в любой программе так.
S>>>Помилуйте, были Си (процедурный язык), Lisp\Ocaml (фп языки), prolog (лп). Языков тьма. Тот же Erlang был. Но вот почему-то был выбран один из ООП языков. Почему?
G>>Потому что в середине двухтысячных были современные языки: C#, Java, Delphi (еще живой был, но только десктоп)), С++ (который был в глубочайшем кризисе)
G>>Для веба был еще PHP, но он даже на фоне Delphi выглядел как наколеночная поделка.
G>>Так как я знал делфи и хотел развиваться в сторону веба, то выбор был C# или Java — оба ОО-языки.
S>Но опять же, никаких разумных сравнений произведено не было -- loc, сложность поддержки и т.п. Чисто умозрительные вывод.
Серьезно? Только что описал почему фактически не было никаких языков кроме ОО, которые имело смысл изучать. Это сейчас есть не(до)-ОО языки, такие как Go, Rust и Kotlin
S>Вот для кого-то и ДДД выглядит интересно.
Кстати регулярно в чатике дотнета вижу как приходит новичок, который хочет DDD изучать и его всем чатом начинают отговаривать.
S>>>Проверка инварианта делегируются бд, а класс получает результат этой проверки. В бд можно делать еще lock, если что.
G>>Покажешь пример кода, как это сделать?
S>В транзакции что-то посчитать? Закиньте соотв. промт в чатбот.
Какой промпт? Напиши кодом то, что ты словами хочешь объяснить.
Всего-то надо по-ДДДному сделать проверку остатков.
S>>>Ну так переделайте на read-write, а не просто read. И используйте соотв. уровень изоляции, например read commited.
G>>На read commited это и происходит.
G>>Можно for update локи вешать в начале, если меняется та же запись, но на практике есть остаток на складе и список реезрвов, там уже serializable надо.
G>>Но мы уже ушли от работы с объектами в памяти. Что собственно и демонстрирует что в таком режиме самые важные инварианты реализовать нельзя. Надо с базой работать.
S>А бд не с объектами в памяти работает?
нет конечно, она с данными на диске работает.
S>Ну если у нас данные лежат в бд, то естественно что их надо забрать оттуда.
нет конечно, проверка остатков делается без поднятия в память данных.
S>>>Не серьезно -- вы приложили опереточный пример, а в случае DDD речь может идти о 10 или 100 тыс. строк кода минимум.
G>>Это опять вера, что на каком-то количестве строк DDD обязательно сработает. Но примеров нет.
G>>Почему-то все работающие методики работают даже на очень малых примерах.
S>Кто-то считает, что 1 млн лок на пхп без ДДД это уже вилка. Ну вот можно от этой цифры отталкиваться. Хотя сколько людей, столько мнений.
Очередное мнение, которое подкреплено примерно ничем?
S>>>Не одно и то же. Одно дело сравнить алгоритм сортировки на Си vs С#, другое дело какое-нибудь годами разрабатываемое десятками людей ПО.
G>>Любое ПО декомпозируется на отдельные компоненты, о чем говорят все методики и DDD в том числе. если в рамках одного простого компонента нет преимуществ, то почему кто-то думает, что на большом масштабе преимущества появятся?
S>https://ru.wikipedia.org/wiki/%D0%AD%D0%BC%D0%B5%D1%80%D0%B4%D0%B6%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C
А почему такое же свойство не может проявиться у достаточно большой системы без DDD? В чем особенность именно DDD?
S>>>Попросите у чатбота какого-нибудь пример приложения, написанного по DDD.
G>>Я спрашивал, все примеры содержат очень сомнительные решения, которые без паттернов DDD были бы проще и надежнее.
S>Возможно. 101 раз повторю -- это вкусовщина. У разработчика из Я. по ссылке выше на этот счет может быть другое мнение. И это нормально.
Поэтому и не надо отсылать к мнению и чату ГПТ. Приведи просто пример, хоть свой, хоть из интернета, кода с DDD, который по твоему демонстрирует преимущества и я его перепишу без ДДД и сравним по любым формальным (не зависящим от мнения) характеристикам
Пока выглядит так, что ДДД хорош только потому что он кому-то нравится.
Меня интересует более научный подход, когда результат можно как-то измерить.
