Несколько раз знакомился с этой парадигмой по Эвансу, и каждый раз у меня получался один и тот же вывод — архитектурная астронавтика, неприменимая в реальной жизни.

Кто-нибудь вообще видел достаточно сложный код (в идеале опнсорс), написанный по DDD, с бизнес-логикой в методах доменных объектов?

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

scf>Несколько раз знакомился с этой парадигмой по Эвансу, и каждый раз у меня получался один и тот же вывод — архитектурная астронавтика, неприменимая в реальной жизни.

scf>Кто-нибудь вообще видел достаточно сложный код (в идеале опнсорс), написанный по DDD, с бизнес-логикой в методах доменных объектов?

Отличная книжка про ddd https://fsharpforfunandprofit.com/
Но вроде как типы и операции разделять принято.
Была бы возможность делал бы так. Реальный случай. Переделывали бизнес-логику уже готового кода и в результате из-за анемичной модели, где все объекты наследуют интерфейс

IRecord { int Id{get;set;}}

в итоге проект собрался но в отдельных местах сравниваться по Id гайки с болтами.
если же идет к DDD и TDD то реально код становиться самодокументированным, но скорее всего производительность будет ниже.

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

scf>Несколько раз знакомился с этой парадигмой по Эвансу, и каждый раз у меня получался один и тот же вывод — архитектурная астронавтика, неприменимая в реальной жизни.

scf>Кто-нибудь вообще видел достаточно сложный код (в идеале опнсорс), написанный по DDD, с бизнес-логикой в методах доменных объектов?

Да, некоторые элементы ddd получается внедрять, и они упрощают код и повышают его надежность. Полное внедрение же тяжело, я например в проектах, где работал, встречал только одного спеца по ddd, остальные знали и умели ddd фрагментарно. Поэтому код того спеца никто не мог развивать в той же парадигме. Она и правда сложна для освоения на практике.

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

scf>Кто-нибудь вообще видел достаточно сложный код (в идеале опнсорс), написанный по DDD, с бизнес-логикой в методах доменных объектов?

Как бы расшифровка термина подсказывает, что DDD — это не о программировании, а о дизайне, т.е. проектировании. Так что увидеть код невозможно в принципе.

Непосредственно к программированию относится domain-specific language, DSL или по нашему — Предметно-ориентированный язык. Последним я много занимался и он используется на практике во многих коммерческих (и не очень) приложениях. Более того его примеры у каждого на глазах. Даже SQL является по сути DSL — языком запросов. А еще есть разные BNF-подобные описания парсеров, языки описания параметров командной строки, языки описания локализаций и т.п.

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

AA>в итоге проект собрался но в отдельных местах сравниваться по Id гайки с болтами.

Это проблема типизации. Введи отдельные типы для идентификаторов отдельных случаев и будет тебе счастье. Причем это можно сделать практически на любом языке. Например, Id можно обернуть в структуру. Вот пример из Нитры.