Как реализовать ссылки beetwen aggregates в ddd?

Question

В ddd объект может ссылаться на объекты одного и того же агрегата или на другой совокупный корень (но не на объекты внутри другого агрегата).

1. Каким будет эта ссылка?
2. Как метод объекта получит доступ к ссылочному заполнителю?
3. Каков метод объекта, который можно использовать с другим агрегированным корнем?

Для 1. и 2. моя проблема в том, что сущность не должна иметь доступа к репозиториям. Также малые ленивые механизмы загрузки не всегда доступны, и я думаю, что следует избегать по тем же причинам. Итак, когда агрегат загружается репозиторием, должны ли все ссылки каждого объекта в нем быть разрешены (и все ссылки на другие агрегаты будут загружены) репозиторием? Или это «ссылка» только как идентификатор, а кто-то за пределами объекта (командующий или тот, кто загружает агрегат из репозитория и вызывает метод) использует этот идентификатор для загрузки другого агрегата и затем передает его в этот метод как параметр, как в следующем примере?

agg1 = repo1.Load(id); 
agg2 = repo2.Load(agg1.refId); 
agg1.mymethod(agg2); 

Для 3. Я думаю, что только методы, которые должны быть вызваны на другой агрегат будет методы запроса (в ОКК смысле), не меняющие другой агрегат, потому что только один агрегат за одну транзакцию должна быть изменена. Правильно?

Answer 1

Что касается вопросов 1. и 2. то, что вы сказали, прекрасно, и большую часть времени это делается именно так. Вы ссылаетесь на другую совокупность по идентификаторам и извлекаете их вне логики домена, в службу приложений. Причина, по которой вы не должны загружать другие агрегаты в агрегатах (кроме нарушения SRP), заключается в том, что вы не контролируете происходящее, то же самое с ленивой загрузкой. Вы можете легко сделать код, который будет загружать один и тот же агрегат из DB десятка раз, когда он может быть загружен один раз. Вы можете использовать кеш, но будут проблемы с устаревшими данными и т. Д.

Однако иногда вам нужно выполнить «Performance Driven Design» над «DDD», а затем загружать агрегаты в другие агрегаты, но это редко.

Для ответа на вопрос 3. В Query из CQRS вы даже не используете репозитории или агрегаты, потому что вы просто хотите получить данные, там не используется логика домена.