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>Я почитал что там пишут, примеров тоже нет, куча скепсиса, кризис идентичности.
Вы вопрос задайте, возможно там накидают примеры кода по ДДД, где без оного было бы хуже.
