Какой тип реализации будет более подходящим на уровне сервиса? - PullRequest
Новая
       25

Какой тип реализации будет более подходящим на уровне сервиса?

0 голосов
/ 20 декабря 2018

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

Предположим, что мое приложение получит контактную информацию от другого микросервиса, который развернут как Пользовательский API .

  1. Бизнес как файл

В этом подходе в качестве имени файла используется название компании.Внутри файла есть только один публичный метод get, который получает один параметр.Метод вызывает user-api/contact/{id}.

Имя файла : contact.service.js

Метод : get(id) -> contact

API в виде файла

Этот подход объединяет все коммуникации между Пользовательским API и приложением-потребителем в одном файле.Для каждой конечной точки предусмотрен метод для Пользовательский API .

Имя файла : user.service.js

Метод : getContact(id) -> contact

Каковы плюсы и минусы использования этих подходов?

1 Ответ

0 голосов
/ 20 декабря 2018

Этот вопрос на самом деле является скорее вопросом мнения, разные компании / разные разработчики программного обеспечения могут дать вам разные ответы.

Я считаю, что разделение их на отдельные файлы - вплоть до дажеметоды, если логика сложна - очень помогает с ремонтопригодностью / тестированием.

  • Тестирование: если вы используете один и тот же расщепленный шаблон в тестовых файлах - что я имитирую наш код с точки зрения структуры и делаю, я обнаружил, что это помогает людям легче находить код, точно выполнять тестытак, как они хотели их казнить.Something like test contact.service.test.js, где изменение является изолированным, и они могут довольно быстро сразу же выполнить соответствующие тесты.
  • Поддерживаемость: я стараюсь сохранить как можно меньший материал на последнем уровне обслуживания.Это не означает, что все абстрагировано и слой за слоем, вы не можете найти реальный код / ​​но даже тогда я бы разделил сервисы на их методы в разных файлах с супер удобными именами.Таким образом, документирование безумно просто, вы можете просто написать все, что нужно, в одном и том же файле.
  • Обзоры кода: становится намного проще, вынуждает изменение быть небольшим в каждом файле, потому что у вас есть файлы с большим количествомменьше контента.

Задайте эти вопросы себе;

  • Есть ли в ваших сервисах очень сложная логика, которая расширит файлв тысячи строк - что делает труднее документировать / труднее обнаружить ошибки / труднее реорганизовать?Или это меньшие конечные точки, которые логика выгружается в какую-то другую часть системы?

  • Будут ли тесты для этих методов / сервисов существовать в (другом) отдельном файле - имитировать ли шаблон в реализации сервиса?Сможете ли вы вызвать отдельный тест во время тестирования функции?

  • Готовы ли вы принять решение, принятое вами во всех ваших службах?Таким образом, ваш конкретный сервис (ы) может быть относительно небольшим, а как насчет сервиса, который один из ваших коллег мог бы написать и превратить в гигантский 1-строчный файл?

...