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

S>>Все это так, но речь не об этом. Все это ученые и компиляторо писатели. А Эрик Эванс вроде разрабатывал бизнес приложения, и вроде (но не точно) работал в ibm.
G>Честно говоря я вообще не знаю чем ванс занимался до написания книги и есть и значимые проекты в его истории. После он начал заниматься консалтингом.

Я тоже не знаю. Но он как и Фаулер или дядя Боб -- что-то поделали в самом начале, потом решили лопаты продавать книги писать.

S>>Мой вопрос был про кол-во людей, что много людей для того, чтобы технология взлетела и не требуется. Сравнивать их не имеет смысл. У DDD роль гораздо меньше.
G>Вроде ты сам пытался сравнить DDD и ООП.

Неправда. Я сравнивал кол-во апологетов ООП и ДДД. Намек был на то, что и там и там их было немного. Более того, сравнивать их лично не имеет
никакого смысла -- одни делали новую технологию, другие -- методологию.

S>>Ну не скажите, там иногда читают очень достойные доклады. Вот например:
S>>https://www.youtube.com/watch?v=KTy4rqgPOjg
G>Не понял что в этом докладе интересного. Целый час только ради одного слайда с одной мыслью
G>

G>Pain = Strength * Volatility * Distance.
G>Reduce one of them to 0 to minimize the pain of necessary coupling.

Мне понравился, добавил в избранное на пересмотреть. Там много вещей проговаривает помимо этой формулы.


S>>В чем проблема найти компании и продукты у которых работает DDD? Спросите нейронку какую-нибудь. Наверняка что-то есть из докладов по ссылке выше.
G>Еще раз повторить аргумент про лженауки? У кого-то и астрология "работает".
G>Единственный способ доказать что что-то работает — провести эксперимент. Для ДДД это простой эксперимент — берем любой код с DDD, делаем эквивалентный без DDD и сравниваем объективные показатели — объем кода, количество связей между классами итд.
G>Важно взять именно работающий код, решающий задачу от начала до конца.

Мне это не интересно. Вам интересно, вы и делайте. Я хочу донести мысль, что огульно выкидывать ДДД не стоит -- для кого-то на каких-то проектов
он работает. Я работал в компании, которая распиливала монолит на микросервисы по ДДД. Использовали стратегические паттерны. Оправдано или нет -- не знаю, но вроде как-то работало. Опять же ДДД был не в полный рост, а что-то заимствовалось.


S>>А в ООП тоже верят? Ведь есть проекты для которых он избыточен, но все равно будет написано с 95% на каком-нибудь ООП языке.
G>Некоторые не верят, но что это меняет? Современные языки используют ОО-парадигму и часто базовые библиотеки реализованы как библиотеки классов. То есть ты любом случае будешь использовать ООП, даже если сам не придерживаешься ОО-парадигмы.

Некоторые не верят в ДДД, но что это меняет.

S>>Он не про ORM и таблицы в бд.
G>А про что?

101 раз говорю, что там все эти детали скрыты за паттерном Репозиторий. ДДД, кажется, не об этом.

G>Меня интересует подход к проектированию от начала до конца, а не просто в какой-то части, делая вид что других не существует.

Это подход к проектировании на основе проблем бизнеса, а не про орм или таблицы.

S>>Вероятно и у приложения будет один Bounded Context и один микросервис. Что не так?
G>Если order, line и product в одном агрегате, где root это order, то как получить список "лидеры продаж" с топ 30 товаров за месяц.

Какой-то метод добавить в репозиторий, наверное.

S>>Зависит от сложности. Ну найдите людей у которых все по DDD и поговорите с ними. Писать калькулятор по DDD странно, но какой-нибудь банковский софт, где требования регулярно меняются вполне может быть ок. Как обычно -- it depends.
G>См выше про эксперимент. Мнение интересует в последнюю очередь.

Сдается мне, на ООП языках вы стали писать без всяких экспериментов. На основе чьего-то мнения, скорее всего. И, наверное, до сих пор
полет нормальный.

S>>Если сохранять класс, когда у него все ок с инвариантами, то почему нет?
G>Потому что в рамках одного класса нельзя сделать контроль остатков.

Почему?

S>>Для пользователя класса у него всегда должны быть инварианты, пользователь затем может этот класс сохранить.
G>Как описать инвариант: остаток товаров на складе должен быть не меньше суммы зарезервированных?

Вычитать соотв. поля из бд, взяв соотв. лок предварительно, посчитать и в зависимости от, продолжить работу.

S>>А как это может доказать обратное? Зачем вообще что-либо подсчитывать?
G>Затем что нужны объективные измеримые показатели преимуществ того или иного подхода: объем, цикломатическая сложность, вложенность вызовов. Иначе это вера, а не инженерный подход.

См. выше про ООП -- что такое проделывали?

Еще раз -- я не агитирую за ДДД, я против огульного откидывания подходов, мол "не нравится", "не встречал" и т.п. Это субъективщина.
Наверняка можно найти человека с обратным опытом.