Запрос шаблона DDD в C# для агрегатов
Я новичок в DDD, так что терпите меня.
Сценарий Агрегат A и Агрегат B
A связан с B через RelationshipId, который находится на Aggregate B (так что это будет B.A_Id Теперь мне нужно создать B, но есть правило, что я не могу создать B, если B.SalesDate ближе, чем 7 календарных дней от A.ReleaseDate. У меня вопрос по моему CommandHandler на Aggregate B, могу ли я сделать запрос к Aggregate A, чтобы получить A.ReleaseDate, чтобы я мог выполнить процесс проверки того, не превышает ли предоставленный B.SalesDate 7 календарных дней? это часть кода при использовании CommandHandler на агрегате B:
public async Task Handle(AddBCommand command, CancellationToken cancellationToken)
{
if (!command.IsValid())
{
NotifyValidationErrors(command);
return;
}
// this is where I do a query on Aggregate A to get details using the Id (which is A.Id from Aggregate A) selected on UI
var aggregateADetails = await A_Repository.GetFirstAsync(x => x.Id == command.Id);
//if (isCloserthan7Days.)
//{
// NotifyError(string.Empty, "B.SalesDate is 7 days closer than A.ReleaseDate");
// return;
//}
поэтому в этом CommandHandler я создаю 2 репозитория, 1 для B и 1 для A, которые будут использоваться в запросе. Нарушу ли я таким образом правило DDD? Извините, это не так ясно.
Спасибо
Ответы 1
Ваш обработчик команд считается уровнем приложения, а не уровнем домена.
Учитывая вышеизложенное, вполне нормально загрузить агрегат A из обработчика команд и передать данные в агрегат B, но логика должна быть реализована на уровне домена, что означает метод агрегирования B. В общем, то, что делает прикладной уровень (если вы думаете об этом), - это извлечение всех данных, необходимых методу уровня домена для выполнения своей работы. Не имеет значения, что требуемые данные (в данном случае) получены из другого агрегата. Семантически это то же самое, как если бы вы читали свойство из проекции модели чтения этого агрегата, и это нормально в отношении «правил» DDD (хотя в случае, если вы планируете читать из асинхронно сгенерированных прогнозов, вы должны знать о возможности внесения возможных проблем с согласованностью). Важно помнить, что даже если вы готовы читать из агрегата A, в рамках этого изменения вы должны редактировать (и сохранять) только один агрегат.
Что-то, что я не упомянул в моем первоначальном ответе, но должен был, и на что Константин указал в комментариях, является проблема согласованности. Хотя чтение из хранилищ запросов (как я прокомментировал выше) может вызвать возможные проблемы с согласованностью, чтение данных из другого агрегата также может вызвать проблемы с согласованностью, поскольку вы читаете данные из агрегата A, которые могут быть устаревшими к тому времени, когда агрегат B завершит операции и попытается выполнить упорствовать.
(Ответ на EDIT): в вашем примере кода ваш метод представляет собой комбинацию логики уровня приложения и уровня домена. Загрузка из репозиториев - это уровень приложения, но логика, позволяющая решить, следует ли вам действовать в совокупности, должна принадлежать совокупности. Возможно, мне здесь не хватает какой-то информации, но из того немногого, что я вижу на данный момент, я предполагаю, что у вас, вероятно, есть анемичная модель предметной области. Несмотря на это, мой первоначальный ответ все еще актуален.
Вы должны добавить в свой ответ важное замечание о том, что это правило проверяется способом в конечном итоге последовательный.
@ConstantinGalbenu Может быть, я не очень ясен и должен обновить ответ на этот счет, но я не предлагаю использовать асинхронно сгенерированную модель чтения. Я просто сказал, что загрузка агрегата в читать значения поведенчески и семантически аналогична чтению из проекции.
@SKleanthous: да, я знаю, но бизнес-правила, использующие данные из других агрегатов, (как в слове «должны») в конечном итоге согласованы, и разработчик должен знать об этом. Архитектура (Classic или CQRS) значения не имеет.
@ConstantinGalbenu да, вы правы. Исправлю ответ.
Да, агрегат A будет использоваться только для получения A.ReleaseDate и использования его для целей проверки в обработчике команд, остальная логика при сохранении находится на агрегате B, который находится на уровне домена.