DDD: совокупные корни

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

DDD - Как реализовать высокопроизводительные репозитории для поиска .

Когда дело доходит до поиска, я не работаю с «моделью», вместо этого у меня есть специализированные поисковые репозитории, которые возвращают объекты «Сводка» ... то есть «PlanSummary». Это не что иное, как информационные объекты (их можно рассматривать как отчеты), и они не используются в транзакционном смысле - я даже не определяю их в своей библиотеке классов моделей. Создав эти выделенные репозитории и типы, я могу реализовать высокопроизводительные поисковые запросы, которые могут содержать сгруппированные данные (например, счетчик PlannedTraining), не загружая все ассоциации агрегата в память. Как только пользователь выбирает один из этих сводных объектов в пользовательском интерфейсе, я могу использовать идентификатор для получения фактического объекта модели, выполнения транзакционных операций и фиксации изменений.

Итак, для вашей ситуации я бы предоставил эти специализированные поисковые репозитории для всех трех объектов, и когда пользователь желает выполнить или действовать против одного, вы всегда выбираете агрегат Plan, которому он принадлежит.

Таким образом, у вас будет эффективный поиск, в то же время поддерживая единый агрегат с необходимыми инвариантами.

Правка - Пример:

Хорошо, поэтому я предполагаю, что реализация субъективна, но именно так я обработал это в своем приложении, используя в качестве примера агрегат TeamMember. Пример написан на C #.У меня есть две библиотеки классов:

• Модель
• Отчетность

Библиотека модели содержит совокупный класс со всеми задействованными инвариантами, а библиотека отчетов содержит этот простой класс:

public class TeamMemberSummary
{
    public string FirstName { get; set; }

    public string Surname { get; set; }

    public DateTime DateOfBirth { get; set; }

    public bool IsAvailable { get; set; }

    public string MainProductExpertise { get; set; }

    public int ExperienceRating { get; set; }
}

Библиотека отчетов также содержит следующий интерфейс :

public interface ITeamMemberSummaryRepository : IReportRepository<TeamMemberSummary>
{

}

Это интерфейс, который будет использовать уровень приложения (который в моем случае является службами WCF) и будет разрешать реализацию через мой контейнер IoC (Unity). IReportRepository находится в библиотеке Infrastructure.Interface, как и базовая ReportRepositoryBase. Итак, в моей системе есть два разных типа репозиториев - агрегированные репозитории и репозитории отчетов ...

Затем в другой библиотеке, Repositories.Sql, у меня есть реализация:

public class TeamMemberSummaryRepository : ITeamMemberSummaryRepository
{
    public IList<TeamMemberSummary> FindAll<TCriteria>(TCriteria criteria) where TCriteria : ICriteria
    {
        //Write SQL code here

        return new List<TeamMemberSummary>();
    }

    public void Initialise()
    {

    }
}

Итак, на моем уровне приложения:

    public IList<TeamMemberSummary> FindTeamMembers(TeamMemberCriteria criteria)
    {
        ITeamMemberSummaryRepository repository 
            = RepositoryFactory.GetRepository<ITeamMemberSummaryRepository>();

        return repository.FindAll(criteria);

    }

Затем в клиенте пользователь может выбрать один из этих объектов и выполнить действие по отношению к одному из них на уровне приложения, например:

    public void ChangeTeamMembersExperienceRating(Guid teamMemberID, int newExperienceRating)
    {
        ITeamMemberRepository repository
            = RepositoryFactory.GetRepository<ITeamMemberRepository>();

        using(IUnitOfWork unitOfWork = UnitOfWorkFactory.CreateUnitOfWork())
        {
            TeamMember teamMember = repository.GetByID(teamMemberID);

            teamMember.ChangeExperienceRating(newExperienceRating);

            repository.Save(teamMember);
        }
    }