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

S>Здравствуйте, Аноним, Вы писали:

А>>Теперь что предписывает нам DDD.
S>DDD (как и любая другая методология) не предписывает ничего, это просто набор приёмов и определённый стиль решения проблем. Конкретно в случае DDD фишка — выделение стабильной модели в самостоятельный артнефакт, который используется при дизайне всех слоёв системы.

Фишка в том, что попытка оторвать этот "самостоятельный артефакт" от субд приводит к неработающим решениям.

S>В вашем случае никто не запрещает оставить контроль за согласованностью данных за СУБД. Если конечно, невозможность существования заказов без менеджера — это инвариант предметной области, а не хотелка заказчика. В последнем случае вы наоборот, нарушаете DDD, внося в модель заведомо нестабильную и оторванную от реальности информацию. Что будем делать, если менеджер уволится? Или если заказ был оформлен на врио а затем отдан соседнему отделу в рамках реорганизации?
Ты зря прицепился к менеджерам, данные о сотрудниках удалять вообще нельзя, надо ставить дату удаления, иначе много отрицательных эффектов может возникнуть.
Но можно придумать вполне абстрактный пример когда для выполнения некоторого действия с сущностью A требуется предусловие, которое затрагивает множество связанных сущностей B, причем между проверкой предусловий и выполнением действия может пройти время и предусловие не будет выполняться.
Так как UoW и optimistic concurrency не обеспечиваются сериализуемости, то нужны транзакции.

Но тут внезапно оказывается что сущности A и B сделаны в DDDшном стиле и проверка предусловия является "инвариантом предметной области" (хотя ни разу не инвариантом, но тут это не важно). Весь этот код размещен в самих классах предметной области и, соответственно, не может просто открыть транзакцию.
Тогда начинаются пляски с бубном, навешивание атрибутов, AoP для обеспечения транзакций, только делается это все на более высоком уровне, чем сама domain model и получается что транзакции хоть и являются в данном случае частью БЛ, но сама БЛ об этом и не знает, и тестируется без учета транзакционности.

Вот такой вот хороший DDD . Это все вместо Transaction Script в виде

ОткрытьТранзакцию(...);
if(Предусловие(a))
{
    Действие(a);
}
ЗавершитьТранзакцию();

который вызывается прямо из PL кода.


А>>Вместо проверки логики в ХП сделать проверку логики в домене.
S>Не вместо, а в дополнение к. Чтобы найти косяк в бизнес-логике сразу, при попытке начислить зарплату шнурками, а не в момент выдачи их на руки
Тут возникает дублирование усилий, зачем деалть две проверки? Одну в коде, другую в СУБД, причем для этого писать разный код?
Ведь в transaction script можно делать "грязную" (не транзакционную) проверку предусловия, потом спрашивать подтверждение пользователя, а потом уже делать проверку в транзакции. И делать это все будет один и тот же код. А в DDD так нельзя, просто структура классов не позволит это сделать без увеличения связности.

S>Другими словами: не надо гнаться за баззвордами, просто решайте проблемы так, чтобы создавать минимальное количество новых
Угу, для этого достаточно не использовать DDD

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

G>>Вот такой вот хороший DDD . Это все вместо Transaction Script в виде
S>Ну да, жирная модель во всей своей красе. Единственно, не пойму: почему жирная модель == ddd и почему нельзя использовать пассивную модель данных с валидацией in-place и легковесную логику для операций с этой моделью (именно так мы делаем лет 5 и не имеем никаких проблем)? Точнее, почему anemic-подход требует отказаться от DDD?
Скорее наоборот: DDD не приемлит anemic, а как методика анализа ddd очень неплох, только вся суть его заключается в половине первой главы книги эванса, а остальное — фуфло.

G>>Тут возникает дублирование усилий, зачем деалть две проверки? Одну в коде, другую в СУБД, причем для этого писать разный код?
S>Ок, от чего будем отказываться? При условии, что у нас desktop и долгие сеансы редактирования — от получения данных до сохранения легко может пройти с десяток минут?

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

Если сеансы редактирования долгие, то нужно иметь lastmodified поле. Но когда банальный CRUD, его легко сохранять, причем независимо rich или anemic. А вот когда нетривиальна БЛ требует нетривиальных пред- и пост- условий уже становится актуальным вопрос правильного группирования кода чтобы избежать дублирования усилий. Вот тут DDD сливает вчистую.

S>Более того, на практике приходится делать проверки на 3 уровнях:
S>- в UI (хотя там по большей части биндинги к состоянию приложения и к данным)
S>- в самой логике/модели данных — ассерты для отлавливания багов из разряда "быть не может" (например, попытка повторно продать билет или ввести заведомо некорректный инн).
Зачастую эти 2 совпадают, обратное скорее является исключением.

S>- constraints в СУБД — а куда без них?
Не стоит делать, потому что база эволюционирует и корректные вчера данные окажутся некорректными сегодня итд. Констрейнты в субд если будут, то довольно простыми и к делу не относятся.

S>Разумеется, все 3 пересекаются лишь частично.
У меня скорее первые два совпадают полностью, а третье отсутствует совсем.



G>>Ведь в transaction script можно делать "грязную" (не транзакционную) проверку предусловия, потом спрашивать подтверждение пользователя, а потом уже делать проверку в транзакции. И делать это все будет один и тот же код.
S>Ну да, вполне рабочий вариант, при условии, что база используется одним приложением. Увы, это не наш случай.
Да хоть 10, без разницы.

S>Так что хочешь-не хочешь, часть проверок остаётся в СУБД. Справедливости ради, сложные кошмары в триггерах приходилось писать раз 5-10, не больше. Как правило — банальная фильтрация в хранимых процедурах + constraints.

Не должно быть такого, на триггерах имеет смысл денормальзацию поддерживать, но не БЛ. БЛ просто делется в транзакции: сначала проверка предусловий, потом действие, потом проверка постусловий. Если проверка не завершается — транзакция откатывается.
Все проверки выполняются запросами к БД из программного кода.



S>>>Другими словами: не надо гнаться за баззвордами, просто решайте проблемы так, чтобы создавать минимальное количество новых
G>>Угу, для этого достаточно не использовать DDD
S>Повторюсь — у нас какой-то неправильный DDD, он просто работает
Скорее всего это не DDD, спросите у эксперта по DDD

Всем добрй день! Осваиваю методологию Domain Driven Design и появился вопрос к более опытным товарищам.
Излагаю суть.
Пусть у нас есть классы
Manager {Name,...}
Order {Date, Manager,...}
Трбуется реализовать бизнес-правило, что менеджеров нельзя удалять если у них есть хоть один заказ. В Transaction Script, я бы сделал все тупо и просто.
Из контроллера приложения вызвал бы метод удаления менеджера. Сам метод вызвал бы в транзакции хранимую процедуру с сиквела в которой проверил бы if exists (select * from orders..) и если нет заказаов delete from manager where...
Теперь что предписывает нам DDD.
Вместо проверки логики в ХП сделать проверку логики в домене. Для этого видимо надо ввести метод hasOrders() (или свойство HasOrders — не важно) в класс Manager, в момент вызова которого (или, если это свойство, признак бы мапился туда ORM-ом в момент получения объекта из базы). После введения в класс метода. Я из контроллера приложения спрашиваю: if (manager.HasOrders()) managerRepository.Delete(...) или там DAL.Delete(manager). Так?
А как быть с тем моментом, что между тем как своиство было заполнено или даже вызовом метода — проходит время и кто-то другой в базе меняет это значение, т.к. все это вызывается вне транзакции. Тогда в момент удаления данные будут несогласованы.

Паттерн unit of work здесь как-то не очень подходит, он вроде упорядочивает работу по созданию и сохранению.
Открывать транзакцию? А где? В модели — явный бред и нарушение пнринципов DDD. В слое ORM или DAL — не канает, потому, что "получение данных о том есть ли заказы" и "операция удаления" это два разных вызова из слоя управления данными. А между ними идет сравнение. Тогда где, в контроллере приложения? Тоже как-то глупо, ведь тогда контроллер должен знать и о слое ORM/DAL и о том что происходит когда я запрашиваю hasOrders().

В общем, как-то все криво, глупо и запутанно получается. Настявьте на путь истинный.
Спасибо.

Здравствуйте, Аноним, Вы писали:

А>Теперь что предписывает нам DDD.
DDD (как и любая другая методология) не предписывает ничего, это просто набор приёмов и определённый стиль решения проблем. Конкретно в случае DDD фишка — выделение стабильной модели в самостоятельный артнефакт, который используется при дизайне всех слоёв системы.

В вашем случае никто не запрещает оставить контроль за согласованностью данных за СУБД. Если конечно, невозможность существования заказов без менеджера — это инвариант предметной области, а не хотелка заказчика. В последнем случае вы наоборот, нарушаете DDD, внося в модель заведомо нестабильную и оторванную от реальности информацию. Что будем делать, если менеджер уволится? Или если заказ был оформлен на врио а затем отдан соседнему отделу в рамках реорганизации?

Итак, если мы решили, что заказов без ответственных не бывает (например, менеджер перед увольнением обязан сдать преёмнику все свои дела) — зачем убирать проверки из СУБД?

А>Вместо проверки логики в ХП сделать проверку логики в домене.
Не вместо, а в дополнение к. Чтобы найти косяк в бизнес-логике сразу, при попытке начислить зарплату шнурками, а не в момент выдачи их на руки

А>Паттерн unit of work здесь как-то не очень подходит, он вроде упорядочивает работу по созданию и сохранению.
Паттерн UoW ортогонален DDD и никак не влияет на способ валидации производимых изменений. Он всего лишь требует, чтобы эти самые проверки были. А как именно: serialized-транзакцией/optimistic concurrency или триггерами в БД — это шерифа не волнует.

Другими словами: не надо гнаться за баззвордами, просто решайте проблемы так, чтобы создавать минимальное количество новых

Здравствуйте, Аноним, Вы писали:

А>В общем, как-то все криво, глупо и запутанно получается. Настявьте на путь истинный.
А>Спасибо.

Ты уже на истинном пути. Не нужен тебе DDD, как подход к разработке программ он тупо не работает. Как подход к анализу — может быт, но не более того.

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

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

G>Ты зря прицепился к менеджерам, данные о сотрудниках удалять вообще нельзя, надо ставить дату удаления, иначе много отрицательных эффектов может возникнуть.
+1 На практике приходится или хранить в базе текущее положение дел + скидывать историю в ОЛАП, или вести полноценное штатное расписание — с историей, должностями, ставками, заменами, врио и прочими прелестями.

G>Вот такой вот хороший DDD . Это все вместо Transaction Script в виде
Ну да, жирная модель во всей своей красе. Единственно, не пойму: почему жирная модель == ddd и почему нельзя использовать пассивную модель данных с валидацией in-place и легковесную логику для операций с этой моделью (именно так мы делаем лет 5 и не имеем никаких проблем)? Точнее, почему anemic-подход требует отказаться от DDD?

G>Тут возникает дублирование усилий, зачем деалть две проверки? Одну в коде, другую в СУБД, причем для этого писать разный код?
Ок, от чего будем отказываться? При условии, что у нас desktop и долгие сеансы редактирования — от получения данных до сохранения легко может пройти с десяток минут?

Более того, на практике приходится делать проверки на 3 уровнях:
— в UI (хотя там по большей части биндинги к состоянию приложения и к данным)
— в самой логике/модели данных — ассерты для отлавливания багов из разряда "быть не может" (например, попытка повторно продать билет или ввести заведомо некорректный инн).
— constraints в СУБД — а куда без них?
Разумеется, все 3 пересекаются лишь частично.


G>Ведь в transaction script можно делать "грязную" (не транзакционную) проверку предусловия, потом спрашивать подтверждение пользователя, а потом уже делать проверку в транзакции. И делать это все будет один и тот же код.
Ну да, вполне рабочий вариант, при условии, что база используется одним приложением. Увы, это не наш случай. Так что хочешь-не хочешь, часть проверок остаётся в СУБД. Справедливости ради, сложные кошмары в триггерах приходилось писать раз 5-10, не больше. Как правило — банальная фильтрация в хранимых процедурах + constraints.


S>>Другими словами: не надо гнаться за баззвордами, просто решайте проблемы так, чтобы создавать минимальное количество новых
G>Угу, для этого достаточно не использовать DDD
Повторюсь — у нас какой-то неправильный DDD, он просто работает

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

S>Здравствуйте, Аноним, Вы писали:

А>>Теперь что предписывает нам DDD.
S>DDD (как и любая другая методология) не предписывает ничего, это просто набор приёмов и определённый стиль решения проблем. Конкретно в случае DDD фишка — выделение стабильной модели в самостоятельный артнефакт, который используется при дизайне всех слоёв системы.

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

S>Итак, если мы решили, что заказов без ответственных не бывает (например, менеджер перед увольнением обязан сдать преёмнику все свои дела) — зачем убирать проверки из СУБД?

А>>Вместо проверки логики в ХП сделать проверку логики в домене.
S>Не вместо, а в дополнение к. Чтобы найти косяк в бизнес-логике сразу, при попытке начислить зарплату шнурками, а не в момент выдачи их на руки

А>>Паттерн unit of work здесь как-то не очень подходит, он вроде упорядочивает работу по созданию и сохранению.
S>Паттерн UoW ортогонален DDD и никак не влияет на способ валидации производимых изменений. Он всего лишь требует, чтобы эти самые проверки были. А как именно: serialized-транзакцией/optimistic concurrency или триггерами в БД — это шерифа не волнует.

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

Спасибо за ответ.
Собственно, по сути, ниже все уже сказали, что я хотел сказать.
Базворды это понятно, но я за ними и не гонюсь. Тут вопрос в другом, я собссно всюю жизнь программирвоал в стиле: постоянные данные в объектах, которые не содержат логики, а являются просто оберткой записи в таблице. Бизнес логика в методах, в слое DAL и в ХП в БД. Все критичные операции выполняемые вместе завернуты в транзакции. "Объектность" использовалась только в толством клиенте, в случаях, когда это было удобно (например функционал для построения разных отчетов удобнее сделать в виде классов, с наследованием и т.д. и т.п.). Оказывается все это идеологически неверно, категорически не подходит для больших систем и отстает от передовых методик напсиания программ (хотя на практике немаленькая система уже 5 лет успешно живет и продолжат развиваться. Да, должен признать есть кое-какие проблемы с дублированием кода и размыванием логики по бд и серверу приложений — но они решаются).

Так вот я и решил изучить, что же нам предлагают прогрессивные (ну конечно уже не такие новые как году в 2004) методики. Начал я с книг Фаулера, Эванса и чтения блогов и обсуждений. Дочитал эванса до 6-ой главы и вот появился такой вопрос. Кстати, сам эванс, приводит в книге отличный пример про редактирование заказа двумя пользователями одновременно, но не дает его решения, а просто отмазывается фразой: "введем дополнительное знание в предметную облась о том что заказ может изменять несколько пользователей". Офигеть сентенция, да в многопользовательских системах почти все могут изменять одновременно несколько пользователей. А решений он не прелагает...неужели для столь тривиальной операции приверженцам DDD надо заново "изобретать" свои блокировки, с блэк джеком и шлюхами. Это извините полная глупость да и лень честно говоря. Кроме того что придется навешивать это почти на все объекты. Можно наделать кучу ошибок. А модель должна "знать" о том, что данные может изменять еще кто-то... Короче муть это все, хорошо в теории но на практике мало осуществимо, имхо.

Касательно "сохранения проверок в БД". Кроме явного дублирвоания кода, от которого мы так бежим, это же прямое нарушение тех принципов о которых говорит и Фаулер, И Эванс. Фаулер рассматривает вынесение логики в БД как чисто оптимизационное решение, Эванс ратует за проверки только в домене. Хорошо, с удалением может не очень удачный пример. А как вам реализация такого бизнес правила: "Менеджер не может уйти в отпуск пока у него есть активные заказы. Активный заказ нельзя назначить на обработку менеджеру который в отпуске." Чистая бизнес логика, не так ли? Однако, если делать две операции "проверку заказов и перевод менеджера в отпуск" и "назначение заказа менеджеру и проверку что тот не в отпуске" — одновременно вне транзакции, то запросто можно получить модель не в согласованном состоянии. Вынесение этого в бд — прямое нарушение DDD, т.к. это чистая бизнес-логика. А таких правил тыща в реальной системе. Так получится вся логика опять окажется либо в СУБД, либо в слое работы с данными где существует понятие "транзакция" (тут уж кому как удобнее). А если оставить все это в домене, как быть с одновременностью, реализовывать блокировки? Т.е. по сути дублировать хорошо отлаженный, безошибочный, быстрый и точный функционал субд, созданный профессионалами. да ни за что в жизни не буду так поступать.

И т.к. я новичек в DDD, суть моего вопроса в том, как обходят это маститые знатоки DDD, т.к. видимо должны быть какие-то "паттерны" или принципально отличная архитектура для таких случаев. А UoW я привел не как оплот DDD, а как паттерн который позволяет решить какую-то конкретную проблему, похожую на ту что я озвучил.

П.С. Я ни в коем случае не противник DDD, сама идея мне нравится и написано красиво, но вот как с практикой. Пока я не разобрался до конца в теме, по этому говорю, что программирование DDD с логикой только в домене и в стиле Persistance Ignore — ну никак не получается у меня представить, хоть ап стенку убейся.

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

G>Здравствуйте, Аноним, Вы писали:

А>>В общем, как-то все криво, глупо и запутанно получается. Настявьте на путь истинный.
А>>Спасибо.

G>Ты уже на истинном пути. Не нужен тебе DDD, как подход к разработке программ он тупо не работает. Как подход к анализу — может быт, но не более того.

Спасибо за ваше мнение! Пока я склоняюсь к такому же выводу, но, все ж продолжу изучение, чтоб разобраться до конца.

G>Тогда начинаются пляски с бубном, навешивание атрибутов, AoP для обеспечения транзакций

Вы не могли бы расшифровать, что такое АоР?

Здравствуйте, Аноним, Вы писали:

А>Базворды это понятно, но я за ними и не гонюсь. Тут вопрос в другом, я собссно всюю жизнь программирвоал в стиле: постоянные данные в объектах, которые не содержат логики, а являются просто оберткой записи в таблице. Бизнес логика в методах, в слое DAL и в ХП в БД.
Ну да, всем привычный anemic. И что в этом плохого?


А> Дочитал эванса до 6-ой главы и вот появился такой вопрос. Кстати, сам эванс, приводит в книге отличный пример про редактирование заказа двумя пользователями одновременно, но не дает его решения, а просто отмазывается фразой: "введем дополнительное знание в предметную облась о том что заказ может изменять несколько пользователей".

С Эвансом поаккуратней: он классный популяризатор, но при этом очень любит коньюктурку. Последние года два он занимается пиаром NoSQL и кассандры. До этого — последовательно заигрывал с фаулером|явой|агилистами. Практически вся вторая часть его книжки — это фаршировка котлет мухами: натягивание DDD на Repository, логика как часть domain и прочая ересь. В результате агилисты больше всего ругают Эванса именно за пристрастие к жирной модели Профессиональный евангелист, что поделать.

Вместе с тем, первая часть — там где он не смешивает бизнес-логику и собственно модель предметной области — маст рид. Одно из лучших пособий по сбору-анализу пользовательских требований.

Со всем остальным — согласен

А>И т.к. я новичек в DDD, суть моего вопроса в том, как обходят это маститые знатоки DDD, т.к. видимо должны быть какие-то "паттерны" или принципально отличная архитектура для таких случаев.
Мастистые знатоки работают консультантами У нас всё устроено вот так

Автор: Sinix
Дата: 10.02.09

. Подробно тему BL vs DDD расписывал вот тут

Автор: Sinix
Дата: 24.12.10

.

Ну и ещё пара бесполезных (потому как ничем не закончились) обсуждений:
http://www.rsdn.ru/forum/design/4074856.aspx?tree=tree

Автор: Cynic
Дата: 11.12.10

http://www.rsdn.ru/forum/design/3548129.aspx?tree=tree

Автор:
Дата: 25.09.09

http://www.rsdn.ru/forum/design/3406168.aspx?tree=tree

Автор: GlebZ
Дата: 27.05.09

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

S>Здравствуйте, Аноним, Вы писали:

А>>Базворды это понятно, но я за ними и не гонюсь. Тут вопрос в другом, я собссно всюю жизнь программирвоал в стиле: постоянные данные в объектах, которые не содержат логики, а являются просто оберткой записи в таблице. Бизнес логика в методах, в слое DAL и в ХП в БД.
S>Ну да, всем привычный anemic. И что в этом плохого?

Да-да, именно так =) Ничего в сущности плохого, я не говорю что плохо и что нет, я просто хочу понять "а как еще".

S>Мастистые знатоки работают консультантами У нас всё устроено вот так

Автор: Sinix
Дата: 10.02.09

. Подробно тему BL vs DDD расписывал вот тут

Автор: Sinix
Дата: 24.12.10

.

S>Ну и ещё пара бесполезных (потому как ничем не закончились) обсуждений:
S>http://www.rsdn.ru/forum/design/4074856.aspx?tree=tree

Автор: Cynic
Дата: 11.12.10

S>http://www.rsdn.ru/forum/design/3548129.aspx?tree=tree

Автор:
Дата: 25.09.09

S>http://www.rsdn.ru/forum/design/3406168.aspx?tree=tree

Автор: GlebZ
Дата: 27.05.09

Большое спасибо вам за ответ и за ссылки, на выходных засяду за прочтение!

Здравствуйте, Аноним, Вы писали:

А>Большое спасибо вам за ответ и за ссылки, на выходных засяду за прочтение!
Только не воспринимайте всё всерьёз, в основном по ссылкам обычные разборки — кто кого имел в виду

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

S>Здравствуйте, Аноним, Вы писали:

А>>Большое спасибо вам за ответ и за ссылки, на выходных засяду за прочтение!
S>Только не воспринимайте всё всерьёз, в основном по ссылкам обычные разборки — кто кого имел в виду

Ниче-ниче, и дискуссии полезно почитать, ведь иногда и вправду в споре может родиться истина =)

Здравствуйте, Аноним, Вы писали:

А>Ниче-ниче, и дискуссии полезно почитать, ведь иногда и вправду в споре может родиться истина =)
В тех, где участвовал я — она повесилась. От скуки

Здравствуйте, Аноним, Вы писали:

G>>Тогда начинаются пляски с бубном, навешивание атрибутов, AoP для обеспечения транзакций

А>Вы не могли бы расшифровать, что такое АоР?

Aspect-Oriented Programming

Здравствуйте, Аноним, Вы писали:

А>Всем добрй день! Осваиваю методологию Domain Driven Design и появился вопрос к более опытным товарищам.
А>Излагаю суть.
А>Пусть у нас есть классы
А>Manager {Name,...}
А>Order {Date, Manager,...}
А>Трбуется реализовать бизнес-правило, что менеджеров нельзя удалять если у них есть хоть один заказ. В Transaction Script, я бы сделал все тупо и просто.
Более того, есть более быстрый путь, сразу удалять менеджера, а тем если что ловить эксепшены связанный с нарушением целостных данных по внешним ключам.

А>Из контроллера приложения вызвал бы метод удаления менеджера.
Что такое контроллер приложения?

А>Сам метод вызвал бы в транзакции хранимую процедуру с сиквела в которой проверил бы if exists (select * from orders..) и если нет заказаов delete from manager where...
Это уже и не transaction script, просто логика в хранимках. transaction script такой подход являлся бы когда, stateless код на сервере приложений контроллировал бы поток вычислений над анемичными объектами с get/set методами, например:

class ManagerService {
    ...
    private OrderService orderService;
    ...
    public void delete(Manager manager) throws CannotDeleteManagerException {
       long managerId = manager.getId();
       if (orderService.existsOrders(managerId)) {
          CannotDeleteManagerException exception = new CannotDeleteManagerException();
          exception.setManagerId(managerId);
          exception.setHasOrders(true);
          throw exception;
       }
       ...
    } 
    ...
}

А>Теперь что предписывает нам DDD.
А>Вместо проверки логики в ХП сделать проверку логики в домене. Для этого видимо надо ввести метод hasOrders() (или свойство HasOrders — не важно) в класс Manager, в момент вызова которого (или, если это свойство, признак бы мапился туда ORM-ом в момент получения объекта из базы). После введения в класс метода. Я из контроллера приложения спрашиваю: if (manager.HasOrders()) managerRepository.Delete(...) или там DAL.Delete(manager). Так?
Нет. А может и да, но manager.HasOrders() имеет глубочайшее отличие с точки зрения DDD от manager.CanDelete().

А>А как быть с тем моментом, что между тем как своиство было заполнено или даже вызовом метода — проходит время и кто-то другой в базе меняет это значение, т.к. все это вызывается вне транзакции. Тогда в момент удаления данные будут несогласованы.
А>Паттерн unit of work здесь как-то не очень подходит, он вроде упорядочивает работу по созданию и сохранению.
А>Открывать транзакцию? А где? В модели — явный бред и нарушение пнринципов DDD. В слое ORM или DAL — не канает, потому, что "получение данных о том есть ли заказы" и "операция удаления" это два разных вызова из слоя управления данными. А между ними идет сравнение. Тогда где, в контроллере приложения? Тоже как-то глупо, ведь тогда контроллер должен знать и о слое ORM/DAL и о том что происходит когда я запрашиваю hasOrders().
Всё точно так же как и при процедурном программировании, открываешь транцакцию на методе сервиса, через AOP или XML/IoC или аннотации, или что сегодня большая редкость явным открытии транзакции в коде, затем сервис считывает у ДАО или в вашем понимании Repository граф объектов, запускает на нем, бизнесс операцию и передает граф объектов обратно в ДАО на сохранение, то есть жирная модель хоть и statefull но живет в рамках одной бизнесс транзакции, а сервис поддерживает аппарат искусственного дыхания для жирной модели.


А>В общем, как-то все криво, глупо и запутанно получается. Настявьте на путь истинный.
А>Спасибо.
Тренеруйтесь, всё придёт с опытом, только не пытайтесь сразу, на ключевых проектах применять жирную модель, желательно начать внедрять её где-то скраю на задворках, где нет риска получить по шапке, и есть возможность ошибаться, так как какой бы уродливой не была анемик, но обычно объяснить последовательность прохождения запроса через View->(Controller|Presenter) -> Service -> Dao -> СУБД вчерашнему студенту занимает день или пол-дня и полностью провалить проекты с анемик достаточно трудно.