Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Все это так, но речь не об этом. Все это ученые и компиляторо писатели. А Эрик Эванс вроде разрабатывал бизнес приложения, и вроде (но не точно) работал в ibm.
G>>Честно говоря я вообще не знаю чем ванс занимался до написания книги и есть и значимые проекты в его истории. После он начал заниматься консалтингом.
S>Я тоже не знаю. Но он как и Фаулер или дядя Боб -- что-то поделали в самом начале, потом решили лопаты продавать книги писать.
Товарищ Мартин свой опыт описывает во множестве книг, например он участвовал в разработке Rational Rose в IBM, где видимо и упорролся в "компонентность", что легло в основу его книги clean architecture. Фаулер не был выдающимся инженером, но он был "computer scientist" — изучал существующие методики, и придумывал новые, о чем очень много писал статей в доинтернетную эпоху. Он стоял у истоков Agile вместе с Беком и фактически ввел в обиход термин "рефакторинг".
А что касается Эванса — я вообще не нашел историю чем он занимался до книги и каких-то достижений после публикации тоже нет. Других книг он не выпускал.
Мне кажется что товарищ эванс вообще является подставным лицом, и DDD придумал Фаулер, но по причине неполного содержания книги, несвойственного Фаулеру, выпустил не под своим именем, а нашел соавтора.
S>>>В чем проблема найти компании и продукты у которых работает DDD? Спросите нейронку какую-нибудь. Наверняка что-то есть из докладов по ссылке выше.
G>>Еще раз повторить аргумент про лженауки? 
У кого-то и астрология "работает".
G>>Единственный способ доказать что что-то работает — провести эксперимент. Для ДДД это простой эксперимент — берем любой код с DDD, делаем эквивалентный без DDD и сравниваем объективные показатели — объем кода, количество связей между классами итд.
G>>Важно взять именно работающий код, решающий задачу от начала до конца.
S>Мне это не интересно. Вам интересно, вы и делайте.
S>Я хочу донести мысль, что огульно выкидывать ДДД не стоит -- для кого-то на каких-то проектов он работает.
Это опять слепая вера. Если хотите сказать что DDD работает лучше чем нажимать рандомные кнопки на клавиатуре, то конечно работает. Как и любая методика проектирования и любые паттерны. Если мы говорим о применении конкретных паттернов, то появляются вопросы эффективности, но которые уже 20 лет нет ответа.
S>Я работал в компании, которая распиливала монолит на микросервисы по ДДД. Использовали стратегические паттерны.
Какие паттерны?
S>>>Он не про ORM и таблицы в бд.
G>>А про что?
S>101 раз говорю, что там все эти детали скрыты за паттерном Репозиторий. ДДД, кажется, не об этом.
А о чем тогда? Ну это смешно: как только в обсуждении DDD доходит до деталей, то "DDD не об этом". Что DDD в любой программе касается 10% не самого важного кода. Поэтому чтобы такие спекуляции исключить я и предлагаю взять пример, который от начала до конца работает.
G>>Меня интересует подход к проектированию от начала до конца, а не просто в какой-то части, делая вид что других не существует.
S>Это подход к проектировании на основе проблем бизнеса, а не про орм или таблицы.
В результате ведь получается код, который рабоает с таблицами в БД и, вероятнее всего, с помощью ORM. Или нет?
S>>>Вероятно и у приложения будет один Bounded Context и один микросервис. Что не так?
G>>Если order, line и product в одном агрегате, где root это order, то как получить список "лидеры продаж" с топ 30 товаров за месяц.
S>Какой-то метод добавить в репозиторий, наверное.
Это тот самый репозитрий, который скрывает детали? То есть важнейшее требования — это "детали", которые надо "скрывать"?
И кто вызывать будет этот репозиторий?
S>>>Зависит от сложности. Ну найдите людей у которых все по DDD и поговорите с ними. Писать калькулятор по DDD странно, но какой-нибудь банковский софт, где требования регулярно меняются вполне может быть ок. Как обычно -- it depends.
G>>См выше про эксперимент. Мнение интересует в последнюю очередь.
S>Сдается мне, на ООП языках вы стали писать без всяких экспериментов. На основе чьего-то мнения, скорее всего. И, наверное, до сих пор полет нормальный.
Я писать на ОО языках начал потому что выбора не было. Сейчас сложно найти мейнстримный язык без ООП, а когда я начинал таких вообще не было.
S>>>Если сохранять класс, когда у него все ок с инвариантами, то почему нет?
G>>Потому что в рамках одного класса нельзя сделать контроль остатков.
S>Почему?
По факту. Работа с объектами в памяти не обеспечивает изоляцию транзакций, когда есть более одного экземпляра процесса.
S>>>Для пользователя класса у него всегда должны быть инварианты, пользователь затем может этот класс сохранить.
G>>Как описать инвариант: остаток товаров на складе должен быть не меньше суммы зарезервированных?
S>Вычитать соотв. поля из бд, взяв соотв. лок предварительно, посчитать и в зависимости от, продолжить работу.
Два пользователя параллельно пытаются зарезервировать товар.
Один процесс считает данные из базы и считает предварительно. У него ок.
Второй процесс (на другом сервере) параллельно также считывает данные из базы и у него тоже ок.
Оба процесса создают резрвы товаров и сумма резервов получается больше остатка.
S>>>А как это может доказать обратное? Зачем вообще что-либо подсчитывать?
G>>Затем что нужны объективные измеримые показатели преимуществ того или иного подхода: объем, цикломатическая сложность, вложенность вызовов. Иначе это вера, а не инженерный подход.
S>См. выше про ООП -- что такое проделывали?
Конечно, я даже пример минимальный скидывал, который иллюстрирует преимущества. Любые подходы без ООП увеличивают объемы дублирующегося кода кода, при той же функцинальности.
S>Еще раз -- я не агитирую за ДДД, я против огульного откидывания подходов, мол "не нравится", "не встречал" и т.п. Это субъективщина.
S>Наверняка можно найти человека с обратным опытом.
Так давайте найдем, пусть пример покажет. Мы же не только что прочитали про DDD, напомню что я уже 16ый год участвую в эти дискуссиях и пока НИ РАЗУ не увидел примера приложения, сделанного 100% по DDD, чтобы оно не содержало дублирования, множества лишних связей, проблем быстродействия и ошибок несогласованности данных.
