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


G>Я не утрирую, с 2002 по 2017 год было всего два визионера про DDD, и одна достойная книга про DDD, не на Java, и Фаулер, который активно это все пиарил в своем блоге.

А сколько визионеров надо, что технология взлетела? У ООП много было визионеров, тоже 2-3 человека.
По DDD уже много лет конференции проводят -- https://www.youtube.com/@ddd_eu

G>Поэтому я, возможно, чуть лучше разбираюсь в DDD. Кстати Фаулера я прочитал в 2008, а Эванса в 2009, и еще тогда многие подходы мне показались сомнительными.

Я же не спорю с этим.

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

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

G>Без сравнения в равных условиях мы не узнаем.

Ну такой себе странный аргумент. Лишних денег ни у кого нету. Разве что у крупняка типа ibm, которые могут себе позволить несколько назависимых отделов
для решения одной проблемы.


S>>Что в этом плохого и кто с этим спорит? В DDD есть паттерн Repository, как раз и отвечает за сохранение главных
S>>доменных сущностей, наверное и таблицы соотв. должны были быть.
G>Ты не на тот вопрос отвечаешь. Вопрос такой: является ли набор классов без логики, с которыми работает ORM, "моделью предметной области" в понимании ДДД (по книгам)? Я могу однозначно сказать что нет.

Без логики не является, и? ORM это не тот уровень, на котором стоит обсуждать DDD. Он там спрятан за паnтерном Repository.

G>>>А кто сказал что отсутствие "объектов доменной модели" автоматически приводит к плохому решению задачи?
S>>Никто не сказал, просто это, кхм, странно. Задача софта эмулировать соотв. процессы. Как можно эмулировать что-то без соотв. сущностей?
G>Еще раз. DDD как набор паттернов, говорит нам:
G>- Domain Model это набор классов с данными поведением, которые соответствуют существительным в едином языке, выработанным между бизнесом и командой разработки
G>- Вся бизнес-логика (Core Domain) должна быть описана как взаимодействие этих объектов

Там вроде, все строится вокруг взаимодействия AggregateRoot'ов, которые несколько больше чем просто "набор классов с данными поведением".

G>Я сейчас не буду говорить о том, насколько корректно так проектировать программы, но без этого DDD не будет считаться DDD.

Я пока понять не могу, что в этом плохого?

G>>>И кто сказал что наличие "объектов доменной модели" автоматически приводит к хорошему решению задачи?

S>>Никто не сказал. Но вот вопрос -- что лучше, плохо написанная программа, которая прилично решает соотв. проблему предметной
S>>области, или хорошо написанная программа, которая плохо решает заявленную проблему? Вы лично за какую бы программу заплатили бы
S>>деньги?
G>Я не очень понимаю критериев оценки "хорошо или плохо". Программа может проблему решать или не решать. Мне как пользователю совершенно без разницы есть там "модель предметной области" или нет. Если две программы одинаково решают мою (не какой-то абстрактной предметной области) проблему, то выберу ту, которая дешевле по совокупной стоимости владения.

Это уход от ответа на конкретный вопрос. Речь не про одинаково. Программа написана хорошо, но не покрывает большую часть use-case'ов или
делает это криво. У другой все наоборот. Какой программист больше заработает денег?

S>>Я вообще не вижу противоречия между хорошим кодом и объектами доменной модели. Это прям какая-то странная дихотомия.
G>Я тоже не вижу. Качество программы и наличие в ней domain model — вещи ортогональные, то есть независимые друг от друга.

Ну т.е. можно использовать excel в качестве бд, написан хорошо, данные хранить может. Или все же возьмем что-то другое для
данной задачи?


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

Этот код может и ракету в космос запустить, дальше что?


S>>Какая разница, софт есть софт.
G>У Эрика Липперта — он написал гораздо больше и полезнее, чем Фаулер, Эванс и Вернон вместе взятые и вообще крутой программист и инженер — есть потрясающая серия статей Wizards and Warriors, которую я даже перевел на хабре
G>В пятой части он сформулировал тезис:
G>

G>Программа должна поддерживать согласованное состояние перед лицом попыток пользователя (клиента) изменить это состояние

G>Когда у нас программа работает на компьютере пользователя, в одном процессе (адресном пространстве) и её состояние существует столько, сколько существует процесс, то требования будут одни. Если состояние программы хранится во внешнем хранилище, к которому надо обращаться по ненадежной сети, причем обращаться могут несколько пользователей из разных экземпляров программы, то требования получатся совершенно другие. И подходы к проектированию и реализации программы будут разные.

Инвариант класса называется, которое Б. Мейер лет 40 назад ввел в обиход. При чем здесь бд или сеть?


S>>Вот цитата Б. Мейера отсюда -- https://bertrandmeyer.com/2012/11/27/why-so-many-features/
S>>

S>>It is easy to complain about software bloat, and examples of needlessly complex system abound. But your bloat may be my lifeline, and what I dismiss as superfluous may for you be essential. To paraphrase a comment by Ichbiah, the designer of Ada, small systems solve small problems. Outside of academic prototypes it is inevitable that a successful software system will grow in complexity if it is to address the variety of users’ needs and circumstances. What matters is not size but consistency: maintaining a well-defined architecture that can sustain that growth without imperiling the system’s fundamental solidity and elegance.

S>>Апологет DDD какай-то такой целью и задавались. На сколько вышло --
G>Очень сложно проверить насколько им удалось придумать архитектуру, которая сохраняет целостность и элегантность длительное время.

S>>Народ использует, конференции ежегодные проводят, значит кому-то заходит.
G>Это вообще не показатель. Я пережил столько хайпов в ИТ уже, и после каждого еще долго оставались толпы фанатов "кому заходит".
G>Тем более есть проблема: кроме Clean Architecture и DDD в медийном поле вообще не существует других подходов. У альтернативы ДДД даже названия собственного нет, она состоит из применения принципов YAGNI, KISS, DRY, top-down подхода к проектированию и разработке, частично SOLID.
G>Многое кстати было описано в книге Pragmatic Programmer Ханта и Томаса (2000 год), то есть за пар лет до фаулера-эванса и там нет такой категоричной упоротости на ООП. Несмотря на то, что части сведений в книге устарели я, с вашего позволения, буду называть подход — Прагматичным Программированием или Прагматичным Проектированием, сокрушённо ПП



G>>>Сколько нам нужно функций, чтобы DDD с его паттернами стало давать какой-то профит?
S>>Какой-то дурацкий вопрос, если честно. Типа сколько нужно людей, чтобы лампочку вкрутить. Вы какую-то цифру ждете?
S>>Она, скорее всего, у каждого будет своя.
G>Любую теорию, например теорию о полезности DDD, можно считать научной если существует хотя бы один эксперимент, который может теорию опровергнуть, даже если он еще не проведен. Это называется критерий фальсифицируемости поппера.
G>А если такого эксперимента не существует, то это уже не теория, а вера.

Я не понимаю о чем идет речь и к чему эти странные вопросы и ответы с отсылками на Поппера. Возьмите какой-нибудь проект по DDD
и подсчитай в нем ф-ии.

Если так подходить, то сколько надо строк кода, чтобы ООП давал выхлоп? Может < писать на Си или ФЯ? Но почему-то для простейших задачи
на сотни строк кода все равно используют ООП. Странно, правда?

G>Я посмотрел историю избранных другими моих сообщений. Я холиварю против DDD с 2009 года (видимо сразу после того как книгу прочитал), с тех пор НИ ОДНОГО ПРИМЕРА, демонстрирующего превосходства DDD над ПП в рамках этого форума. Я даже для прикола брал ndddsample и переписывал на код без DDD — получалось компактнее при том же функционале. Жалко код уже утерян.

Ну нету здесь таких, ищите на хабре, например или на SO.