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

NL>>>Если у меня спрашивают пример с уровнями изоляции транзакций — я просто кидаю ссылку на книжку или статью, где это хорошо описано. Так в данно случае и поступил.
G>>Уровни изоляции достаточно формально описаны в стандарте, которому следуют многие создатели движков СУБД. А "domain model" вообще не имеет формального описания, более того многие даже буксуют на том, чтобы формально очертить границы DDD.
G>>Поэтому ссылки на курсы и статьи по теме без сравнения разных подходов и хотя бы попоыток формализации — не более ем аппеляция к авторитетам, которые в общем-то не очень авторитеты.
NL>В DDD точно так же формально все описано.
Увы, нет. "Формально" это когда два человека могут прочитать описание и сделать одинаково работающий код.

NL>Есть бизнесовые сервисы, есть application сервисы, есть репозитории, есть абстрактные фабрики, есть агрегаты.
Это все не нужно для того, чтобы сделать приложение. У меня больше одного работающего приложения, в которых нет репозитоиев, абстрактных фабрик и агрегатов.

Резонно возникает вопрос: а что такое вообще DDD? Может это просто набор паттернов? Тогда расматривать DDD в отрыве от задачи нет смысла. И как понять где начинается и кончается DDD? Если я использую application service это DDD?

В книжке эванса делется упор на то, что DDD это методика анализа в первую очередь, ubiquitous language и все такое. Правда даже в книге эванса переход от анализа к проектированию описан мутно. Нам предлагается самостоятельно понять как нам предметную область поделить на агрегаты и сервисы.

А может DDD это фреймворк, где в некоторую готовую структуру надо написатьсвою логику? Но я такой структуры не видел.