Более чистой DDD'y, вероятно, было бы, вероятно, моделировать User
и Case
как агрегированные корни, а затем моделировать их отношения с объектом роли RelatedCase
(который агрегируется внутри User
и поэтому должен быть каскад = "все-удалить-сирота").
Совокупные корни должны быть сохранены в репозиториях, которые (если вы делегируете вызов session.Save(...)
) дадут вам нужный идентификатор в то время, когда вы можете его использовать.
Тогда роль может (и по моему опыту часто будет, по крайней мере, через какое-то время) содержать дополнительную информацию, которая характеризует отношения, и не принадлежит ни пользователю, ни делу. Допустим, отношения отслеживают, почему пользователь и дело связаны.
Так ваш код может выглядеть так:
var case = caseFactory.Create("name");
caseRepository.Save(case);
user.AssignCase(case, "Assigned by some dude");
- и внутри AddCase:
public void AddCase(Case case, string reason)
{
cases.Add(new RelatedCase(case, reason));
}
Это, на мой взгляд, самый красивый способ моделировать подобные вещи, но вы, конечно, будете немного наказаны с точки зрения производительности. Если для вас важнее симпатичная модель, то вам стоит заняться чем-то вроде этого.