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

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


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

S>>>По DDD уже много лет конференции проводят -- https://www.youtube.com/@ddd_eu
G>>Это вообще не показатель. Люди астрологией и гомеопатией занимаются, гораздо больше лет конференции проводят. Программисты тоже подвержены влиянию всяких лженаук.
S>Ну не скажите, там иногда читают очень достойные доклады. Вот например:
S>https://www.youtube.com/watch?v=KTy4rqgPOjg
Не понял что в этом докладе интересного. Целый час только ради одного слайда с одной мыслью

Pain = Strength * Volatility * Distance.

Reduce one of them to 0 to minimize the pain of necessary coupling.

S>>>Ну какая-то статистика и выборка же есть, этим не одна компания занимается. Метрики такие, например, что сложный софт развивается.
S>>>Т.е. заказчик деньги платит не зря.
G>>Повторить аргумент про лженауки?

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

Важно взять именно работающий код, решающий задачу от начала до конца.

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

S>>>Без логики не является, и? ORM это не тот уровень, на котором стоит обсуждать DDD.
G>>Почему? Меня интересует только подход к проектированию и написанию кода. Если DDD не про это, то я не понимаю о чем говорить.
S>Он не про ORM и таблицы в бд.
А про что?
Меня интересует подход к проектированию от начала до конца, а не просто в какой-то части, делая вид что других не существует.


G>>>>- Вся бизнес-логика (Core Domain) должна быть описана как взаимодействие этих объектов
S>>>Там вроде, все строится вокруг взаимодействия AggregateRoot'ов, которые несколько больше чем просто "набор классов с данными поведением".
G>>Если для реализации поведения вам нужны Order, Line и Product, то они попадут в один агрегат.
S>Вероятно и у приложения будет один Bounded Context и один микросервис. Что не так?
Если order, line и product в одном агрегате, где root это order, то как получить список "лидеры продаж" с топ 30 товаров за месяц.

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


S>>>Инвариант класса называется, которое Б. Мейер лет 40 назад ввел в обиход. При чем здесь бд или сеть?
G>>Инвариантность класса не помогает обеспечить целостность состояния во внешнем хранилище.
S>Если сохранять класс, когда у него все ок с инвариантами, то почему нет?
Потому что в рамках одного класса нельзя сделать контроль остатков.

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

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

S>А как люди с коллекциями на Си работали и работают?
Плохо, у C до сих пор нет стандартной библиотеки коллекций, в каждой прикладной библиотеки свои коллекции, которые могут быть несовместимы между ними.

S>Тем не менее пишут же зачем-то на C#.
Потому C# и дотнет предоставляет много готовых согласованных между собой библиотек для решения прикладных задач.