Списки объектов-значений в распределенном домене

Question

Мне нужны некоторые ощутимые рекомендации по реализации списка объектов-значений в моем распределенном приложении DDD. Вот что у меня есть:

Мое приложение основано на приложении-службе RESTful, работающем на сервере, предоставляющем услуги нескольким клиентским приложениям. Одна из моих сущностей, Клиент, имеет свойство Region, которое содержит ссылку на один из многих типов значений Region. Список регионов хранится в серверной базе данных, но мы НЕ предоставляем интерфейс для поддержки этого списка. Любые изменения будут внесены непосредственно в базу данных (поскольку это будет происходить редко), и, скорее всего, это будут изменения имени, а не добавление / удаление. В некоторых случаях, например, при экспансии на новый рынок, может быть добавлен новый элемент, поэтому необходимо, чтобы список был «динамическим».

При редактировании записи Customer в одном из клиентских интерфейсов мне нужно отобразить список регионов в раскрывающемся списке с выбранным элементом, связанным со свойством Region объекта Customer домена.

Я могу справиться с пользовательским интерфейсом, но не совсем понятно, как список регионов должен быть получен и поддерживаться на уровне моего домена. У меня есть отдельный RegionRepository или список должен быть получен из CustomerRespository? Что, если Customer был единственным объектом, который ссылался на объект Value? Если бы несколько объектов ссылались на VO, это изменило бы подход?

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

Хотя элементы списка являются «ключевыми», они не соответствуют определению сущности с их собственной идентификацией и не существуют, кроме как в контексте объекта родительского домена (в данном случае, Customer). Итак, я предполагаю, что они являются объектами значения, и это нормально. Но, опять же, мне неясно, как я должен структурировать свое приложение, чтобы клиенты могли получать список виртуальных организаций для сценария, подобного тому, что я описал выше.

Answer 1

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

Answer 2

Вы можете разместить их где угодно.Если вы решите выставить свойство и внедрить репозиторий, это не нарушит никакого соглашения DDD.

В качестве примера я использую следующее:

interface IAddress
{
    List<State> GetStatesByCountry (string country);
}

и у меня также есть

interface ITaxes
{
    List<State> GetStates ();
}

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