Как построить архитектуру @Service с Spring и MongoRepository?

Question

[Biogenezis]

Здравствуйте, у меня стоит проблема в постройке архитектуры. Я хочу создать "Сервис коротких ссылок". Идея такова: гет запросом приходят три ссылки, на разные контроллеры - ссылка на iOS приложение, Android и PWA/SPA. После принятия ссылок идёт сверка с базой данных, есть ли подобные ссылки в базе, есть - вернуть готовую короткую ссылку. Если нет - создать документ в MongoDB, заполнить поля ссылок и вернуть короткую ссылку. Во время переходе по короткой ссылке определяется устройство пользователя. Соответственно если это было Android устройство - редирект идёт в play market и т.д. Вопрос состоит в том, как сделать единый @Service , который будет вычислять бизнес логику, для разных контроллеров, на которые приходят разные ссылки, которые сопоставляются с соответственными полями и как это будет выглядеть? Мой вариант подразумевает три разных сервера, под каждый контроллер, что является не правильным. Какой вариант будет оптимальным решением?

Answer 1

[ads83]

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

// В Андроид контроллере
service.processAndroidLink(link)
// В iOS контроллере
service.processMacLink(link)

// в самом сервисе будут такие методы:
public void processAndroidLink(URL link) {
  // подготавливаем данные для записи
  URL androidLink = link;
  URL iosLink = createIosLink(link);
  URL webLink = createWebLink(link);
  var doc = prepareDocument(andriodLink, iosLink, webLink);
  save(doc);
}
public void processWebLink(URL link) {
  // подготавливаем данные для записи
  URL androidLink = createAndroidLink(link);
  URL iosLink = createIosLink(link);
  URL webLink = link;
  var doc = prepareDocument(andriodLink, iosLink, webLink);
  save(doc);
}
private void save(document) {сохраняем в MongoDB}
}

Понятно, что вместо URL может быть любой другой тип.

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

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