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


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

Вот видео про то, как использовали DDD в Яндекс 360
https://www.youtube.com/watch?v=N-ro_8te98A

В комментариях нашел ссылку на тг канал по DDD
https://t.me/iDDDqd
Вот тут можно, наверное, с людьми про их проекты поговорить и похоливарить.

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