Подходит ли агрегированный корень с глубокой иерархией в DDD?

Да, в DDD можно использовать глубокую иерархию.

Это нормально, что я получаю очень обширный агрегат? - если реальность настолько сложна, и ваша модель предметной области настолько лучшая, насколько вы можете понять, вы получите сложный агрегированный корень .

Да, Form должен быть совокупным корнем.

все другие объекты должны быть объектами значений - неправильно, все остальные объекты должны быть неагрегированными корневыми объектами (с идентификатором) без репозитория для их получения. Объект значения не имеет идентификатора, и равенство объектов значения определяется только его значениями атрибутов, а не равенством идентификаторов (подробнее здесь).

В этом случае FormRepository будет загроможден всеми видами CRUD-методов для дочерних объектов - нет, репозиторий должен содержать только методы, относящиеся к совокупному корню, т.е. Get<T> , Save<T> where T : IAggregateRoot, как только вы получите экземпляр совокупного корня, вы можно перемещаться с помощью атрибутов и методов, чтобы получить то, что вам нужно. Пример:

var formId = 23;
var form = _formRepository.Get(formId);
var firstGroup = form.Sections.First().Group().First();

или лучше

var groupIndex = 1;
var firstGroup = form.GetGroupAt(groupIndex);

куда

public Group GetGroupAt(int groupIndex)
{
    Sections.First().Group().ElementAt(groupIndex);
}

Я считаю, что такое представление может легко привести к проблемам с производительностью - если вы используете CQRS, вы будете вызывать какой-то Form метод домена из обработчика команд, и если вы используете NHibernate для сохранения сущностей, он по умолчанию будет использовать ленивую загрузку и будет загружать только Form из БД, а затем будет загружать только те сущности, которых вы действительно касаетесь, так, например, Sections.First() загрузит все разделы из БД, но не группы и все остальное. Для запроса вы должны создать FormDto (объект передачи данных) и другие, возможно, сглаженные dtos, чтобы получить данные в нужной вам форме (которая может отличаться от структуры ваших сущностей, а пользовательский интерфейс может управлять структурой dto). Взгляните на мою blog для получения информации о DDD / CQRS / NHibernate / Repository

Несмотря на то, что ответ был принят, я подумал, что могу добавить свои 2 цента:

Глубокие иерархии (вероятно) прекрасны, но помните, что идея агрегата состоит в том, чтобы фактически предотвратить это. Я склонен думать о сущностях в совокупности по следующим направлениям:

"Имеет ли этот объект какое-либо значение без AR?"

Поскольку у меня нет контекста w.r.t. вашу модель буду использовать _1 _ / _ 2_. Имеет ли OrderLine какое-либо значение без Order? Могу ли я сделать что-нибудь (поведение) с самой строкой заказа? Очевидный ответ - «нет».

К каждой модели нужно будет относиться в зависимости от контекста. Но владение не обязательно означает сдерживание.

Это может быть легче увидеть, когда вы работаете с отдельными ограниченными контекстами при условии правильного определения BC :)

В вашем случае Answer может не иметь значения без Question. Но, возможно, Question может жить в QuestionBank BC, и конкретный вопрос может использоваться как в вашем Examination BC, так и в вашем Enrollment BC. Все это полностью придумано, поэтому это будет зависеть от вашего контекста.

Поэтому, если Question может быть AR, тогда вопросы, принадлежащие вашему Form AR, могут быть просто объектом значения или даже простым идентификатором вопроса.