Пересекающие агрегаты

Question

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

Однако в то же время вам действительно следует попытаться инкапсулировать свои данные так, чтобы свойства / поля были защищенными или приватными.

Поэтому мой вопрос заключается в следующем:Если поля защищены / приватны, как вы должны просматривать совокупность?

На данный момент я настроил его следующим образом:Я помечаю все свойства моей модели предметной области как внутренние, а методы для "настройки" помечены как защищенные.Таким образом, по крайней мере, ничто за пределами модели не может получить доступ к свойствам, но объекты внутри модели могут получить доступ к свойствам других объектов, и я по-прежнему разрешаю настройку свойств только изнутри самого объекта.

Несмотря на то, что я сделал это, я все еще чувствую, что это должно применяться только к свойствам для других агрегированных объектов (я имею в виду, что "имя" клиента по-прежнему будет закрытым, но их "Заказы" должны быть помечены как внутренние, чтобы разрешить обход из Customer -> Orders -> etc.)

Есть ли у кого-нибудь какие-нибудь рекомендации по этому поводу?

Редактировать:

Позвольте мне попытаться привести более конкретный пример для ответа на этот вопрос:У меня есть два объекта в моем графе объектов:Книжная полка и Книга.Допустим, ради этого примера, что Bookshelf является совокупным корнем, и что Книги хранятся на книжной полке, поэтому являются просто объектами внутри совокупности (Bookshelf содержит коллекцию книг).

Я хочу написать метод для добавления новой книги на книжную полку.Следуя рекомендациям DDD, я считаю, что мне следует написать метод для класса Bookshelf, такой как AddBook (Книга-справочник).

Однако что, если существует бизнес-требование, согласно которому ни одна книга с таким названием не может быть добавлена на книжную полку?Мне нужна некоторая логика в книжной полке.Метод AddBook для проверки коллекции книг, чтобы убедиться, что эта книга еще не существует.

Проблема сейчас в том, что я не могу этого сделать, поскольку я написал объект Book красиво инкапсулированным способом, а его свойство "Name" недоступно для общественности.

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

Answer 1

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

Другими словами, нет ничего плохого в том, чтобы предоставлять свойство Book name для Bookshelf, но было бы неправильно (в смысле рекомендаций DDD) предоставлять название Книги другим агрегатам.Было бы также неправильно выставлять изменяемую коллекцию книг.Предоставление коллекции, доступной только для чтения, следует делать с осторожностью - это может быть признаком нарушения инкапсуляции.

Отвечает ли это на ваш вопрос?

Answer 2

Тот Самый Шаблон посетителя это типичный механизм обхода.