Блог

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

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

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

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

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

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

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

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

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

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

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

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

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