Мне нужно конкретное руководство по реализации списка объектов значений в моем распределенном приложении DDD. Вот что у меня есть:
Мое приложение основано на приложении службы RESTful, работающем на сервере, предоставляющем услуги нескольким клиентским приложениям. Одна из моих сущностей, «Клиент», имеет свойство «Регион», которое содержит ссылку на один из многих типов значений «Регион». Список регионов хранится во внутренней базе данных, но мы НЕ предоставляем интерфейс для ведения этого списка. Любые изменения будут внесены непосредственно в базу данных (поскольку это будет происходить нечасто) и, скорее всего, будут связаны с изменением имени, а не с добавлением / удалением. В некоторых случаях, например, при выходе на новый рынок, может быть добавлен новый товар, поэтому список должен быть «динамическим».
При редактировании записи клиента в одном из пользовательских интерфейсов клиента мне нужно отобразить список регионов в раскрывающемся списке с выбранным элементом, связанным со свойством Region объекта домена клиента.
Я могу обрабатывать его со стороны пользовательского интерфейса, но не знаю, как следует получать и поддерживать список регионов на моем уровне домена. Есть ли у меня отдельный RegionRepository или список должен быть получен из CustomerRespository? Что, если бы Клиент был единственной сущностью, которая ссылалась на объект значения? Если несколько организаций ссылаются на ВО, изменит ли это подход?
На самом деле у меня есть много таких типов поиска, и я не хочу создавать отдельный репозиторий (и веб-сервис) для каждого, если это не рекомендуется. Я думал об одной службе поиска для API, но не решаюсь реализовать, пока не пойму, какое влияние окажет этот маршрут.
Хотя элементы списка «привязаны к ключу», они не соответствуют определению сущности с их собственными идентификаторами и не существуют, кроме как в контексте объекта родительского домена (в данном случае, «Заказчик»). Итак, я предполагаю, что это объекты-значения, и это нормально. Но, опять же, мне неясно, как я должен структурировать свое приложение, чтобы клиенты могли получать список ВО для сценария, подобного тому, что я описал выше.
