Здравствуйте, 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.
