S>>Я тоже не знаю. Но он как и Фаулер или дядя Боб -- что-то поделали в самом начале, потом решили лопаты продавать книги писать. G>Товарищ Мартин свой опыт описывает во множестве книг, например он участвовал в разработке Rational Rose в IBM, где видимо и упорролся в "компонентность", что легло в основу его книги clean architecture. Фаулер не был выдающимся инженером, но он был "computer scientist" — изучал существующие методики, и придумывал новые, о чем очень много писал статей в доинтернетную эпоху. Он стоял у истоков Agile вместе с Беком и фактически ввел в обиход термин "рефакторинг".
Чем DDD хуже истоков agile и термина рефакторинг?
G>А что касается Эванса — я вообще не нашел историю чем он занимался до книги и каких-то достижений после публикации тоже нет. Других книг он не выпускал. G>Мне кажется что товарищ эванс вообще является подставным лицом, и DDD придумал Фаулер, но по причине неполного содержания книги, несвойственного Фаулеру, выпустил не под своим именем, а нашел соавтора.
Мне не кажется, что Эванс чем-то хуже Фаулера. Оба губошлепы.
S>>Мне это не интересно. Вам интересно, вы и делайте. S>>Я хочу донести мысль, что огульно выкидывать ДДД не стоит -- для кого-то на каких-то проектов он работает. G>Это опять слепая вера. Если хотите сказать что DDD работает лучше чем нажимать рандомные кнопки на клавиатуре, то конечно работает. Как и любая методика проектирования и любые паттерны. Если мы говорим о применении конкретных паттернов, то появляются вопросы эффективности, но которые уже 20 лет нет ответа.
S>>Я работал в компании, которая распиливала монолит на микросервисы по ДДД. Использовали стратегические паттерны. G>Какие паттерны?
https://habr.com/ru/articles/787460/
S>>101 раз говорю, что там все эти детали скрыты за паттерном Репозиторий. ДДД, кажется, не об этом. G>А о чем тогда? Ну это смешно: как только в обсуждении DDD доходит до деталей, то "DDD не об этом". Что DDD в любой программе касается 10% не самого важного кода. Поэтому чтобы такие спекуляции исключить я и предлагаю взять пример, который от начала до конца работает.
Ну поищите пример программы в гугле, в чем проблема?
S>>Это подход к проектировании на основе проблем бизнеса, а не про орм или таблицы. G>В результате ведь получается код, который рабоает с таблицами в БД и, вероятнее всего, с помощью ORM. Или нет?
Какие-то технологии будет использоваться, но при чем здесь DDD? DDD это методология, а не технология.
S>>Какой-то метод добавить в репозиторий, наверное. G>Это тот самый репозитрий, который скрывает детали? То есть важнейшее требования — это "детали", которые надо "скрывать"?
Детали реализации -- да, скрывает. Добавьте соотв. метод в соотв. интерфейс и всех делов.
G>И кто вызывать будет этот репозиторий?
Тот, кому нужен соотв. функционал.
S>>Сдается мне, на ООП языках вы стали писать без всяких экспериментов. На основе чьего-то мнения, скорее всего. И, наверное, до сих пор полет нормальный. G>Я писать на ОО языках начал потому что выбора не было. Сейчас сложно найти мейнстримный язык без ООП, а когда я начинал таких вообще не было.
Помилуйте, были Си (процедурный язык), Lisp\Ocaml (фп языки), prolog (лп). Языков тьма. Тот же Erlang был. Но вот почему-то был выбран один
из ООП языков. Почему?
S>>Почему? G>По факту. Работа с объектами в памяти не обеспечивает изоляцию транзакций, когда есть более одного экземпляра процесса.
Проверка инварианта делегируются бд, а класс получает результат этой проверки. В бд можно делать еще lock, если что.
S>>Вычитать соотв. поля из бд, взяв соотв. лок предварительно, посчитать и в зависимости от, продолжить работу. G>Два пользователя параллельно пытаются зарезервировать товар. G>Один процесс считает данные из базы и считает предварительно. У него ок. G>Второй процесс (на другом сервере) параллельно также считывает данные из базы и у него тоже ок. G>Оба процесса создают резрвы товаров и сумма резервов получается больше остатка.
Ну так переделайте на read-write, а не просто read. И используйте соотв. уровень изоляции, например read commited.
S>>См. выше про ООП -- что такое проделывали? G>Конечно, я даже пример минимальный скидывал, который иллюстрирует преимущества. Любые подходы без ООП увеличивают объемы дублирующегося кода кода, при той же функцинальности.
Не серьезно -- вы приложили опереточный пример, а в случае DDD речь может идти о 10 или 100 тыс. строк кода минимум.
Не одно и то же. Одно дело сравнить алгоритм сортировки на Си vs С#, другое дело какое-нибудь годами разрабатываемое десятками людей ПО.
G>Так давайте найдем, пусть пример покажет. Мы же не только что прочитали про DDD, напомню что я уже 16ый год участвую в эти дискуссиях и пока НИ РАЗУ не увидел примера приложения, сделанного 100% по DDD, чтобы оно не содержало дублирования, множества лишних связей, проблем быстродействия и ошибок несогласованности данных.
Попросите у чатбота какого-нибудь пример приложения, написанного по DDD.
Здравствуйте, gandjustas, Вы писали:
S>>Еще раз -- я не агитирую за ДДД, я против огульного откидывания подходов, мол "не нравится", "не встречал" и т.п. Это субъективщина. S>>Наверняка можно найти человека с обратным опытом. G>Так давайте найдем, пусть пример покажет. Мы же не только что прочитали про DDD, напомню что я уже 16ый год участвую в эти дискуссиях и пока НИ РАЗУ не увидел примера приложения, сделанного 100% по DDD, чтобы оно не содержало дублирования, множества лишних связей, проблем быстродействия и ошибок несогласованности данных.
Здравствуйте, Sharov, Вы писали:
S>Чем DDD хуже истоков agile и термина рефакторинг?
Тем что рефакторинг и agile имеет доказанную пользу, а DDD — нет.
S>Мне не кажется, что Эванс чем-то хуже Фаулера. Оба губошлепы.
Эванс вообще ноунейм, у Фаулера есть полезные вещи.
S>>>Мне это не интересно. Вам интересно, вы и делайте. S>>>Я хочу донести мысль, что огульно выкидывать ДДД не стоит -- для кого-то на каких-то проектов он работает. G>>Это опять слепая вера. Если хотите сказать что DDD работает лучше чем нажимать рандомные кнопки на клавиатуре, то конечно работает. Как и любая методика проектирования и любые паттерны. Если мы говорим о применении конкретных паттернов, то появляются вопросы эффективности, но которые уже 20 лет нет ответа.
S>>>Я работал в компании, которая распиливала монолит на микросервисы по ДДД. Использовали стратегические паттерны. G>>Какие паттерны? S>https://habr.com/ru/articles/787460/
Это не про код, а про какую-то философию, тут вообще сложно что-либо оценивать. Меня именно код интересует.
Ну вот мы сделали два разных класса Employee. У меня сразу вопрос: это одна таблица в системе или нет? Если
Как быть если ЗА начинает зависеть от skills (они в разных моделях)?
И вообще calculateWageWithoutTax в employee выглядит крайне сомнительно, для расчета ЗП и налогов нужно такое количество данных подтянуть из всей системы, из-за которых сама система и делает, что прокинуть это все в один Employee выглядит неразумным.
S>>>101 раз говорю, что там все эти детали скрыты за паттерном Репозиторий. ДДД, кажется, не об этом. G>>А о чем тогда? Ну это смешно: как только в обсуждении DDD доходит до деталей, то "DDD не об этом". Что DDD в любой программе касается 10% не самого важного кода. Поэтому чтобы такие спекуляции исключить я и предлагаю взять пример, который от начала до конца работает. S>Ну поищите пример программы в гугле, в чем проблема?
Нет ни одного, который не вызывает вопросов целесообразности применения тех или иных паттернов.
Вот даже "стратегические паттерны" из статьи выше вопросы вызывают, это даже до кода не дошли.
S>>>Это подход к проектировании на основе проблем бизнеса, а не про орм или таблицы. G>>В результате ведь получается код, который рабоает с таблицами в БД и, вероятнее всего, с помощью ORM. Или нет? S>Какие-то технологии будет использоваться, но при чем здесь DDD? DDD это методология, а не технология.
DDD это набор паттернов, которые вроде как должны хорошо работать в каких-то сценарияхх, но на проверку они все плохо работают.
В любой книге про DDD 80% это паттерны и 20% это какие-то философские вещи.
S>>>Какой-то метод добавить в репозиторий, наверное. G>>Это тот самый репозитрий, который скрывает детали? То есть важнейшее требования — это "детали", которые надо "скрывать"? S>Детали реализации -- да, скрывает. Добавьте соотв. метод в соотв. интерфейс и всех делов.
Еще зар: проверка остатков это важнейшая часть бизнес-логики, ради которой система и создается. Это стало "деталями" которые надо скрывать.
G>>И кто вызывать будет этот репозиторий? S>Тот, кому нужен соотв. функционал.
Функционал нужен пользователю. Пользователь нажимает кнопки, кнопки вызывают хэндлеры. Вызывать репозиторий из хэндлера? А где тогда DDD?
S>>>Сдается мне, на ООП языках вы стали писать без всяких экспериментов. На основе чьего-то мнения, скорее всего. И, наверное, до сих пор полет нормальный. G>>Я писать на ОО языках начал потому что выбора не было. Сейчас сложно найти мейнстримный язык без ООП, а когда я начинал таких вообще не было.
S>Помилуйте, были Си (процедурный язык), Lisp\Ocaml (фп языки), prolog (лп). Языков тьма. Тот же Erlang был. Но вот почему-то был выбран один из ООП языков. Почему?
Потому что в середине двухтысячных были современные языки: C#, Java, Delphi (еще живой был, но только десктоп)), С++ (который был в глубочайшем кризисе)
Для веба был еще PHP, но он даже на фоне Delphi выглядел как наколеночная поделка.
Так как я знал делфи и хотел развиваться в сторону веба, то выбор был C# или Java — оба ОО-языки.
S>>>Почему? G>>По факту. Работа с объектами в памяти не обеспечивает изоляцию транзакций, когда есть более одного экземпляра процесса. S>Проверка инварианта делегируются бд, а класс получает результат этой проверки. В бд можно делать еще lock, если что.
Покажешь пример кода, как это сделать?
S>>>Вычитать соотв. поля из бд, взяв соотв. лок предварительно, посчитать и в зависимости от, продолжить работу. G>>Два пользователя параллельно пытаются зарезервировать товар. G>>Один процесс считает данные из базы и считает предварительно. У него ок. G>>Второй процесс (на другом сервере) параллельно также считывает данные из базы и у него тоже ок. G>>Оба процесса создают резрвы товаров и сумма резервов получается больше остатка. S>Ну так переделайте на read-write, а не просто read. И используйте соотв. уровень изоляции, например read commited.
На read commited это и происходит.
Можно for update локи вешать в начале, если меняется та же запись, но на практике есть остаток на складе и список реезрвов, там уже serializable надо.
Но мы уже ушли от работы с объектами в памяти. Что собственно и демонстрирует что в таком режиме самые важные инварианты реализовать нельзя. Надо с базой работать.
S>>>См. выше про ООП -- что такое проделывали? G>>Конечно, я даже пример минимальный скидывал, который иллюстрирует преимущества. Любые подходы без ООП увеличивают объемы дублирующегося кода кода, при той же функцинальности.
S>Не серьезно -- вы приложили опереточный пример, а в случае DDD речь может идти о 10 или 100 тыс. строк кода минимум.
Это опять вера, что на каком-то количестве строк DDD обязательно сработает. Но примеров нет.
Почему-то все работающие методики работают даже на очень малых примерах.
S>Не одно и то же. Одно дело сравнить алгоритм сортировки на Си vs С#, другое дело какое-нибудь годами разрабатываемое десятками людей ПО.
Любое ПО декомпозируется на отдельные компоненты, о чем говорят все методики и DDD в том числе. если в рамках одного простого компонента нет преимуществ, то почему кто-то думает, что на большом масштабе преимущества появятся?
G>>Так давайте найдем, пусть пример покажет. Мы же не только что прочитали про DDD, напомню что я уже 16ый год участвую в эти дискуссиях и пока НИ РАЗУ не увидел примера приложения, сделанного 100% по DDD, чтобы оно не содержало дублирования, множества лишних связей, проблем быстродействия и ошибок несогласованности данных. S>Попросите у чатбота какого-нибудь пример приложения, написанного по DDD.
Я спрашивал, все примеры содержат очень сомнительные решения, которые без паттернов DDD были бы проще и надежнее.
Здравствуйте, Sharov, Вы писали:
S>Вот видео про то, как использовали DDD в Яндекс 360 S>https://www.youtube.com/watch?v=N-ro_8te98A
Многовато болтологии. Про eventstorming я идею не выкупил, как оно соотносится со сложными моделями. например упомянутым ранее расчетом ЗП, отпускных, налогов и прочих выплат итд. По большому счету яндекс 360 это набор независимых сервисов, каждый из которых имеет простую относительно предметную область. Сложнее всего интеграции выглядят интеграции между сервисами, тут и правда может помочь eventstorming, но это не про запутанность, а не неочевидность "модели".
Много пиарят книжу Хононова, она и правда хороша, в одно месте описывает современные паттерны микросервисной архитектуры, но это уже позднее переосмысление
Про недостатки очень верно сказал.
1) DDD это сложно, а сложность должна окупатся хоть както, и вот из разговора я так и не понял за счет чего окупается, на чем в итоге экономят.
2) Имеет проблемы с быстродействием. Соответственно для нагруженной системы я бы не выбирал DDD, странно что в яндекс 360 используют такой подход. Может быть они его используют в ненагруженных частях?
S>В комментариях нашел ссылку на тг канал по DDD S>https://t.me/iDDDqd
Всего 1000 участников...
В чатике только по дотнету 8,5к, по 1С десятки тысяч.
S>Вот тут можно, наверное, с людьми про их проекты поговорить и похоливарить.
Они там сами справляются, на любое негативное мнение по поводу ДДД говорят что автор не понимает бизнес.
Здравствуйте, gandjustas, Вы писали:
G>Много пиарят книжу Хононова, она и правда хороша, в одно месте описывает современные паттерны микросервисной архитектуры, но это уже позднее переосмысление
G>Про недостатки очень верно сказал. G>1) DDD это сложно, а сложность должна окупатся хоть както, и вот из разговора я так и не понял за счет чего окупается, на чем в итоге экономят.
Блин, ну он же говорит, что работал в мамбе где было 1млн loc на пхп. И там, например, анкета могла быть в 50 разных контекстах. И если бы
не ДДД, то по его мнению, было бы очень и очень плохо. Т.е. окупается поддерживаемостью.
G>2) Имеет проблемы с быстродействием. Соответственно для нагруженной системы я бы не выбирал DDD, странно что в яндекс 360 используют такой подход. Может быть они его используют в ненагруженных частях?
Не знаю. Но в целом может быть, т.к. абстракций там накручивают не мало.
S>>В комментариях нашел ссылку на тг канал по DDD S>>https://t.me/iDDDqd G>Всего 1000 участников... G>В чатике только по дотнету 8,5к, по 1С десятки тысяч.
И? Вы еще с общим чатиком по программированию сравните. дотнет -- технология, ддд -- одна из возможных методологий для разработки ПО
на той же дотнет. Все, кмк, естественно.
S>>Вот тут можно, наверное, с людьми про их проекты поговорить и похоливарить. G>Они там сами справляются, на любое негативное мнение по поводу ДДД говорят что автор не понимает бизнес.
Вы хотели с кем-то пообщаться за 16 лет, вот пожалуйста. Это в любом сообществе так. Идите в группу дотнет и начните рассказывать
про преимущества ручной сборки мусора.
Кодом людям нужно помогать!
Re[30]: Что если не разделять строго dto, entity, bo...
Здравствуйте, gandjustas, Вы писали:
S>>Чем DDD хуже истоков agile и термина рефакторинг? G>Тем что рефакторинг и agile имеет доказанную пользу, а DDD — нет.
Для разработчика из видео выше это будет не так -- у него ДДД имеет доказанную пользу. Короче, это субъективщина.
S>>>>Я работал в компании, которая распиливала монолит на микросервисы по ДДД. Использовали стратегические паттерны. G>>>Какие паттерны? S>>https://habr.com/ru/articles/787460/ G>Это не про код, а про какую-то философию, тут вообще сложно что-либо оценивать. Меня именно код интересует. G>Ну вот мы сделали два разных класса Employee. У меня сразу вопрос: это одна таблица в системе или нет? Если
Это можно решить в самый последний момент, согласно ДДД. Это детали.
G>Как быть если ЗА начинает зависеть от skills (они в разных моделях)? G>И вообще calculateWageWithoutTax в employee выглядит крайне сомнительно, для расчета ЗП и налогов нужно такое количество данных подтянуть из всей системы, из-за которых сама система и делает, что прокинуть это все в один Employee выглядит неразумным.
Значит нужен какой-то другой agg root.
G>DDD это набор паттернов, которые вроде как должны хорошо работать в каких-то сценарияхх, но на проверку они все плохо работают. G>В любой книге про DDD 80% это паттерны и 20% это какие-то философские вещи.
На мой взгляд, скорее это методология, а не набор готовых рецептов. По-отдельности применять можно, но сложно.
Точнее уже разбили на стратегически и тактические паттерны.
G>Функционал нужен пользователю. Пользователь нажимает кнопки, кнопки вызывают хэндлеры. Вызывать репозиторий из хэндлера? А где тогда DDD?
Значит тут и репозиторий особо не нужен, обычный DAL.
S>>Помилуйте, были Си (процедурный язык), Lisp\Ocaml (фп языки), prolog (лп). Языков тьма. Тот же Erlang был. Но вот почему-то был выбран один из ООП языков. Почему? G>Потому что в середине двухтысячных были современные языки: C#, Java, Delphi (еще живой был, но только десктоп)), С++ (который был в глубочайшем кризисе) G>Для веба был еще PHP, но он даже на фоне Delphi выглядел как наколеночная поделка. G>Так как я знал делфи и хотел развиваться в сторону веба, то выбор был C# или Java — оба ОО-языки.
Но опять же, никаких разумных сравнений произведено не было -- loc, сложность поддержки и т.п. Чисто умозрительные вывод. Вот для кого-то
и ДДД выглядит интересно.
S>>Проверка инварианта делегируются бд, а класс получает результат этой проверки. В бд можно делать еще lock, если что. G>Покажешь пример кода, как это сделать?
В транзакции что-то посчитать? Закиньте соотв. промт в чатбот.
S>>Ну так переделайте на read-write, а не просто read. И используйте соотв. уровень изоляции, например read commited. G>На read commited это и происходит. G>Можно for update локи вешать в начале, если меняется та же запись, но на практике есть остаток на складе и список реезрвов, там уже serializable надо. G>Но мы уже ушли от работы с объектами в памяти. Что собственно и демонстрирует что в таком режиме самые важные инварианты реализовать нельзя. Надо с базой работать.
А бд не с объектами в памяти работает? Ну если у нас данные лежат в бд, то естественно что их надо забрать оттуда.
S>>Не серьезно -- вы приложили опереточный пример, а в случае DDD речь может идти о 10 или 100 тыс. строк кода минимум. G>Это опять вера, что на каком-то количестве строк DDD обязательно сработает. Но примеров нет. G>Почему-то все работающие методики работают даже на очень малых примерах.
Кто-то считает, что 1 млн лок на пхп без ДДД это уже вилка. Ну вот можно от этой цифры отталкиваться. Хотя сколько людей, столько мнений.
S>>Не одно и то же. Одно дело сравнить алгоритм сортировки на Си vs С#, другое дело какое-нибудь годами разрабатываемое десятками людей ПО. G>Любое ПО декомпозируется на отдельные компоненты, о чем говорят все методики и DDD в том числе. если в рамках одного простого компонента нет преимуществ, то почему кто-то думает, что на большом масштабе преимущества появятся?
S>>Попросите у чатбота какого-нибудь пример приложения, написанного по DDD. G>Я спрашивал, все примеры содержат очень сомнительные решения, которые без паттернов DDD были бы проще и надежнее.
Возможно. 101 раз повторю -- это вкусовщина. У разработчика из Я. по ссылке выше на этот счет может быть другое мнение. И это нормально.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Много пиарят книжу Хононова, она и правда хороша, в одно месте описывает современные паттерны микросервисной архитектуры, но это уже позднее переосмысление
G>>Про недостатки очень верно сказал. G>>1) DDD это сложно, а сложность должна окупатся хоть както, и вот из разговора я так и не понял за счет чего окупается, на чем в итоге экономят.
S>Блин, ну он же говорит, что работал в мамбе где было 1млн loc на пхп. И там, например, анкета могла быть в 50 разных контекстах. И если бы не ДДД, то по его мнению, было бы очень и очень плохо. Т.е. окупается поддерживаемостью.
Опять предлагаете довериться мнению третьего человека, не смотря в код?
S>>>В комментариях нашел ссылку на тг канал по DDD S>>>https://t.me/iDDDqd G>>Всего 1000 участников... G>>В чатике только по дотнету 8,5к, по 1С десятки тысяч.
S>И? Вы еще с общим чатиком по программированию сравните. дотнет -- технология, ддд -- одна из возможных методологий для разработки ПО на той же дотнет. Все, кмк, естественно.
Методологии должны же быть шире технологий, не?
S>>>Вот тут можно, наверное, с людьми про их проекты поговорить и похоливарить. G>>Они там сами справляются, на любое негативное мнение по поводу ДДД говорят что автор не понимает бизнес.
S>Вы хотели с кем-то пообщаться за 16 лет, вот пожалуйста. Это в любом сообществе так.
Я почитал что там пишут, примеров тоже нет, куча скепсиса, кризис идентичности.
S>Идите в группу дотнет и начните рассказывать про преимущества ручной сборки мусора.
Таких преимуществ в природе не существует.
Re[31]: Что если не разделять строго dto, entity, bo...
Здравствуйте, 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, который по твоему демонстрирует преимущества и я его перепишу без ДДД и сравним по любым формальным (не зависящим от мнения) характеристикам
Пока выглядит так, что ДДД хорош только потому что он кому-то нравится.
Меня интересует более научный подход, когда результат можно как-то измерить.
Здравствуйте, gandjustas, Вы писали:
S>>Блин, ну он же говорит, что работал в мамбе где было 1млн loc на пхп. И там, например, анкета могла быть в 50 разных контекстах. И если бы не ДДД, то по его мнению, было бы очень и очень плохо. Т.е. окупается поддерживаемостью. G>Опять предлагаете довериться мнению третьего человека, не смотря в код?
Вашему же я должен довериться, что ДДД не нужен. А его почему-то нет.
S>>И? Вы еще с общим чатиком по программированию сравните. дотнет -- технология, ддд -- одна из возможных методологий для разработки ПО на той же дотнет. Все, кмк, естественно. G>Методологии должны же быть шире технологий, не?
Не факт, книжка по какой-нибудь СУБД или ЯП может в разы оказаться больше чем та же ДДД.
S>>Вы хотели с кем-то пообщаться за 16 лет, вот пожалуйста. Это в любом сообществе так. G>Я почитал что там пишут, примеров тоже нет, куча скепсиса, кризис идентичности.
Вы вопрос задайте, возможно там накидают примеры кода по ДДД, где без оного было бы хуже.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Блин, ну он же говорит, что работал в мамбе где было 1млн loc на пхп. И там, например, анкета могла быть в 50 разных контекстах. И если бы не ДДД, то по его мнению, было бы очень и очень плохо. Т.е. окупается поддерживаемостью. G>>Опять предлагаете довериться мнению третьего человека, не смотря в код?
S>Вашему же я должен довериться, что ДДД не нужен. А его почему-то нет.
Я не призываю моему мнению довериться, я призываю провести эксперимент.
S>>>И? Вы еще с общим чатиком по программированию сравните. дотнет -- технология, ддд -- одна из возможных методологий для разработки ПО на той же дотнет. Все, кмк, естественно. G>>Методологии должны же быть шире технологий, не?
S>Не факт, книжка по какой-нибудь СУБД или ЯП может в разы оказаться больше чем та же ДДД.
А при чем тут книжка если мы про охват аудитории?
S>>>Вы хотели с кем-то пообщаться за 16 лет, вот пожалуйста. Это в любом сообществе так. G>>Я почитал что там пишут, примеров тоже нет, куча скепсиса, кризис идентичности. S>Вы вопрос задайте, возможно там накидают примеры кода по ДДД, где без оного было бы хуже.
Так я тебе задаю, ты же утверждаешь что DDD обладает преимуществами при некоторых условиях. Вот я и хочу прмиер.
Здравствуйте, gandjustas, Вы писали:
S>>Вашему же я должен довериться, что ДДД не нужен. А его почему-то нет. G>Я не призываю моему мнению довериться, я призываю провести эксперимент.
Мне этот эксперимент не интересен. Это долго, и самое главное, дорого. Написать дважды одно и тоже, причем софт должен быть крупный, типа
1млн пхп кода, как прозвучало в видео. И опять же, экспериментов должно быть несколько, вообще говоря много, чтобы что-то утверждать --
1 раз без ДДД лучше, другой -- хуже, ну и какой вывод? Т.е. я не считаю, что это возможно. Ну т.е. возможно, но для компаний типа ibm и проч.
крупняк
S>>Не факт, книжка по какой-нибудь СУБД или ЯП может в разы оказаться больше чем та же ДДД. G>А при чем тут книжка если мы про охват аудитории?
Да, неправ, согласен. Забираю свою аргументацию назад -- очевидно, что по ДДД можно и на пхп писать, на фп, да хоть на Си.
Т.е. я не знаю ответ на свой вопрос -- технология vs методология -- но очевидно, что моя аргументация не верна.
Ну да, ДДД особой популярностью не пользуется. И ладно, я вовсе за него не топлю. Есть что-то полезное, есть что-то не очень.
S>>Вы вопрос задайте, возможно там накидают примеры кода по ДДД, где без оного было бы хуже. G>Так я тебе задаю, ты же утверждаешь что DDD обладает преимуществами при некоторых условиях. Вот я и хочу прмиер.
Я 101 раз говорю, что я не апологет и я не знаю. Выше дал ссылку на практика ДДД, где он озвучивал некоторые условия -- много
кода на пхп, например. Ну поговорите с гпт каким-нибудь. Лично мне подход моделирования бизнеса, выработки общего словаря,
определения доменных границ нравится. Похоже на правду, скажем так. Видел работающий пример разбивки монолита на мс по ДДД.
Другого опыта нету.
Кодом людям нужно помогать!
Re[32]: Что если не разделять строго dto, entity, bo...
Здравствуйте, gandjustas, Вы писали:
S>>Для разработчика из видео выше это будет не так -- у него ДДД имеет доказанную пользу. Короче, это субъективщина. G>Мне кажется ты не понимаешь суть слова "доказанную"...
Доказанную в кавычках, согласен. Типа работает. Применил ДДД -- получилось.
S>>Это можно решить в самый последний момент, согласно ДДД. Это детали. G>Так вот мы пришли к этому моменту. Это одна таблица или нет?
Ну какая разница-то для данного обсуждения?
G>Какой? Почему в этом примере именно Employee? Что этот пример должен был нам сказать? G>Может нам наоборот стоит нарезать задачу контексты по другому? напрмиер на расчет зряплаты, грейдирование, итд. В каждом будут свои "root", а Employee как раз получится один для всех, так как он по сути просто справочник, который точно хранится в одной таблице. G>Я тут не фантазирую, конфигурация 1С ЗУП так устроена. В 1С кстати заложена архитектура Event Sourcing и оптимизации темпоральных запросов (даже проверка остатков прекрасно решается), но в ней нет Domain Model (вернее эта модель полностью соответствует таблицам в БД) и Bounded Context (одна баз — один bounded context).
Ничего не могу сказать по поводу 1С ЗУП, сделали как считали правильным.
S>>На мой взгляд, скорее это методология, а не набор готовых рецептов. По-отдельности применять можно, но сложно. Точнее уже разбили на стратегически и тактические паттерны. G>Пробелма в том, что без "тактических паттернов" методология DDD настолько очевидна, что смысла нет в отдельном названии. G>Она сводится к трем вещам: G>1) Универсальный язык для общения с заказчиком. По сути это раздел "термины и определения" из ТЗ по любому стандарту G>2) Разделение проблемы на области — то что везде называние "модулями" (термин из структурного программирования) или "подсистемами" (термин из системной инженерии). В книге вернона и последующих даже упоминается иерархния (вложенность) областей, также как модули и подсистемы могут иметь вложенность. G>3) Ограниченные контексты — единицы разработки и\или единицы деплоя. G>Еще недавно появился EventStorming — по сути обычные брейнштормы, если отвязать их от event sourcing.
Да, вполне согласен. Не исключаю, что все эти моменты под одну крышуметодологию запихнули и все. Как-то так оно и есть.
Потом решили развивать идею дальше, и появились тактические паттерны и тп.
G>Фактически ничего нового DDD не дает. Мы все это видели например в UML — диграммы компонентов это предметные области, а диаграммы развертывания, диаграммы юзкейсов, процессов и логической структуры.
Ну тактические все-таки что-то новое, все эти agg root, transaction script, entity, values. А так да, взяли отовсюду понемногу.
S>>Значит тут и репозиторий особо не нужен, обычный DAL. G>Так это в любой программе так.
Какой сервис в компании не беру, везде есть Repository. Это уже ~Dal по сути.
S>>Но опять же, никаких разумных сравнений произведено не было -- loc, сложность поддержки и т.п. Чисто умозрительные вывод. G>Серьезно? Только что описал почему фактически не было никаких языков кроме ОО, которые имело смысл изучать. Это сейчас есть не(до)-ОО языки, такие как Go, Rust и Kotlin
Вкусовщина, типа нраится\ не нраится. Могли бы perl для веба взять. Никаких экспериментов по написанию веб приложения на пхп, а потом на C# не было
же?
S>>Вот для кого-то и ДДД выглядит интересно. G>Кстати регулярно в чатике дотнета вижу как приходит новичок, который хочет DDD изучать и его всем чатом начинают отговаривать.
102 заявляю, что я не апологет ДДД. Но вещь интересная и откидывать ее с порога не стоит, там говорят дельный, но возможно,
кому-то очевидные вещи. Но да, новичку изучать ДДД такое себе. Я как бы сам толком его не изучал -- посмотрел некоторое кол-во видео,
почитал хабр и проч. статьи и все. Никаких классиков не читал и не планирую.
G>Какой промпт? Напиши кодом то, что ты словами хочешь объяснить. G>Всего-то надо по-ДДДному сделать проверку остатков.
1) Каким боком это к дискуссии?
2) Речь же шла про инвариант класса, а не ДДДшное исполнение чего-то. Инвариант класса и ДДД противоречат где-то?
S>>А бд не с объектами в памяти работает? G>нет конечно, она с данными на диске работает.
Она(бд) эти данные потом в память себе загоняет и работает с ними. Так что в памяти и работает.
S>>Ну если у нас данные лежат в бд, то естественно что их надо забрать оттуда. G>нет конечно, проверка остатков делается без поднятия в память данных.
Как?
S>>Кто-то считает, что 1 млн лок на пхп без ДДД это уже вилка. Ну вот можно от этой цифры отталкиваться. Хотя сколько людей, столько мнений. G>Очередное мнение, которое подкреплено примерно ничем?
ДДД утв. что если вы правильно поняли бизнес и модель предметной области, то все должно взлететь. Делайте так и все получится.
При этом никто не увт., что если делать иначе, то не получится.
S>>Возможно. 101 раз повторю -- это вкусовщина. У разработчика из Я. по ссылке выше на этот счет может быть другое мнение. И это нормально. G>Поэтому и не надо отсылать к мнению и чату ГПТ. Приведи просто пример, хоть свой, хоть из интернета, кода с DDD, который по твоему демонстрирует преимущества и я его перепишу без ДДД и сравним по любым формальным (не зависящим от мнения) характеристикам
Ну ведь фигней занимаетесь, не будете переписывать огромный софт под 1млн. без ДДД. Ну к чему эта бравада?
Какое-то детсадовское взятие на слабо. Не серьезно.
G>Пока выглядит так, что ДДД хорош только потому что он кому-то нравится. G>Меня интересует более научный подход, когда результат можно как-то измерить.
Я говорил, что он не плох, если кому-то не нравится. Ровно в этом моя позиция. Научный подход в ИТ вещь такая себе -- почему написали на C#, когда
можно было на С++ или вообще на Си? Это бред и демагогия, не нравится, не пользуйтесь. Я вот избирательно что-то для себя в ДДД подчеркнул и мне
хорош, никакого научного подхода не надо.
Блин, ну какой научный подход у agile, рефакторинга и solid?
