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

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


S>1)Сразу оговорюсь, я не апологет DDD. Я ни одно книжки по DDD не прочитал, и много знаю по касательной.
А я прочитал

0) Архитектура Корпоративных Программных Приложений (АКПП) Мартина Фаулера (2002 год), там первый раз в популярной литературе появился термин Domain Model (модель предметной области), но еще никакого DDD не было.

Базовых книг по DDD, которые в принципе определяют что такое DDD, всего две:
1) Domain Driven Design Эрика Эванса (2003 год), а также товарищ Эванс выпустил несколько книг с тем же по сути контентом в 2006, 2013 и 2015 годах.
2) Implementing Domain-Driven Design Вона Вернона (2013 год), который также выпустил справочник на основе своей книги в 2015. Он дополняет DDD событийно-ориентированной архитектурой, CQRS и натягивает это все на Hibernate
Была еще пара книг:
3) Applying DDD (2006 год), там убрали всю философию и попытались сделать примеры кода, но примеры получились настолько невнятные, что практическая ценность книги околонулевая,
4) Patterns, Principles, and Practices of Domain-Driven Design (2015 год), с качественными примерами на .NET и современным, на тот момент, паттернами. По своим идеям и подходам она не приносит ничего нового в DDD по сравнению с книгой Вернона (2).
И все

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

А потом пришел Роберт Мартин, который очень любит слово "Clean" и выпустил свою Clean Architecture, где по сути постулировал, что Clean Architecture = Onion\Hexagon Architecture, которые являются вариантами (разными?) layered arhitecture, у которых в центре Domain Model, поэтому всем нужно DDD, а еще Bounded Contexts в DDD отлично соотносятся с микросервисами.
И после этого материалы по DDD\Clean\Microservices посыпались как из рога изобилия.

Можете и сами проследить вот тут https://github.com/tdonker/domain-driven-design-links

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

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



S>2)
S>

S> То есть "модель предметной области" это типизированное описание схемы БД,

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

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

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


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

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

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

S>>>Ну и самый главный вопрос, а как всему вышеперечисленному мешает оперирование объектами доменной модели?
G>>Никак не мешает и никак не помогает. Хотя зависит от того, что входит в понятие "оперирование объектами доменной модели", так как это может давать ограничения
G>>Например код вида
G>>

G>>ctx.Stock.Where(s => s.Wharehouse == id).ExecuteUpdate(x => x.SetProperty(s => s.Quantity, s => s.Quantity - s.Reserved).x.SetProperty(s => s.Reserved, 0))
G>>

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


S>>>Делаю какой-нибудь реалистичны автотренажер или игру для машин, есть в стандартной библиотеке класс автомобиль, мотор и т.п.?
G>>Мы тут вроде как корпоративные приложения рассматриваем, которые оперируют данными в бд в многпользовательском режиме.
S>Какая разница, софт есть софт.

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

В пятой части он сформулировал тезис:

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

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


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 какай-то такой целью и задавались. На сколько вышло --
Очень сложно проверить насколько им удалось придумать архитектуру, которая сохраняет целостность и элегантность длительное время.

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



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

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