Обходные агрегаты - PullRequest
       3

Обходные агрегаты

2 голосов
/ 02 июля 2010

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

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

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

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

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

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

РЕДАКТИРОВАТЬ:

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

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

Однако, что если есть деловое требование, чтобы ни одна книга с таким же названием не могла быть добавлена ​​вКнижный шкаф.Я хочу, чтобы в методе Bookshelf.AddBook была некоторая логика, чтобы проверить коллекцию книг, чтобы убедиться, что эта книга еще не существует.

Проблема в том, что я не могу сделать это, так как написалОбъект Book в хорошо инкапсулированном виде и его свойство «Имя» не являются общедоступными.

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

Ответы [ 2 ]

2 голосов
/ 03 июля 2010

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

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

Это отвечает на ваш вопрос?

0 голосов
/ 02 июля 2010

Шаблон Visitor является типичным механизмом обхода.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...