Какой предлагается способ реализации _customRoleRepository в следующих примерах? Следующий код выполняется в службе приложений.
var user = _userRepository.GetById(1);
var customRole = _customRoleRepository.GetById(user.CustomRoleId);
or
var user = _userRepository.GetById(1);
var customRole = _customRoleRepository.GetForUser(user);
Учитывая два варианта, я бы, вероятно, выбрал первый, который обеспечивает согласованность доступа по идентификатору.
Если возможно, может быть предпочтительнее загружать настраиваемую роль при загрузке пользователя, чтобы избежать повторного обращения к базе данных, особенно если это обычная операция. Это может быть реализовано как модель чтения.
Это предполагает, что вы правильно смоделировали свои агрегаты... :)
Не хочу этого говорить, но в среде DDD я бы не ответил ни тем, ни другим.
В вашем первом примере репозиторий ролей может не знать о пользовательском домене, что хорошо, но это означает, что приложению необходимо знать, что для получения роли ему необходимо извлечь идентификатор из пользователя, а затем запросить другой репозиторий. Другими словами, приложение действует как сопоставитель между пользователем и ролью.
Во втором примере репозиторию ролей теперь необходимо знать о пользовательском домене. Не очень хорошо, но, с другой стороны, приложению больше не нужно знать о roleId. Так что это хорошо. Классический компромисс между двумя подходами.
Но в обоих случаях приложению по-прежнему нужны два репозитория для получения информации. Что происходит, когда необходимо больше отношений? Количество репозиториев может быстро вырасти, и все превратится в беспорядок.
При проектировании, ориентированном на предметную область, вы должны попытаться мыслить в терминах совокупных корней (AR) и контекстов предметной области. В вашем примере контекста пользователь является AR, а роль становится дочерней. Итак, у вас может быть:
var user = _userFinder.GetById(1);
var customRole = user.CustomRole;
Это скрывает большую часть деталей реализации от вашего приложения и позволяет вам сосредоточиться на том, что на самом деле нужно делать вашим доменным объектам.
Оба одинаково действительны, в зависимости от ваших потребностей. GetForUser было бы хорошо, если вы хотите убедиться, что вызывающий код имеет действительную совокупность пользователей, прежде чем пытаться получить роли, хотя он связывает customRoleRepository со знанием совокупности пользователей, если вы хотите потребовать, чтобы вызывающий код имел действительную совокупность пользователей. Совокупность пользователей, то у этой связи есть цель.
GetByUserId более совместим с GetById и имеет меньшую связанность, поэтому, если в вашем контексте вызов GetByUserId не имеет значения, даже если у клиента нет действительного агрегата пользователя, это тоже нормально.
Если вы загружаете ById, я также обнаружил, что использование типизированных объектов-значений идентификаторов может быть весьма полезным для обеспечения дополнительного уровня безопасности типов - некоторые разговоры о плюсах и минусах здесь https://stackoverflow.com/a/5377460/6720449 и здесь https://groups.google.com/forum/#!topic/dddcqrs/WQ9zRtW3Gbg
