Абстрактные сервисы

Набор правил по созданию абстрактных сервисов

Модули

Абстрактный сервис представляет из себя набор модулей zf2. Обязательно наличие следующих модулей:

  • Core module - модуль, в котором определены базовые сущности и сервисы;
  • Интеграционный модуль, который связывает и настраивает несколько модулей;
  • Модуль, реализующий API для взаимодействия с сервисом;
  • Модуль реализующий API для конкртеного транспорта (REST, шина и т.д.).

Например, для абстрактного сервиса контрактов:


project
  vendor
    nnx-contract
      contract
      contract-core
      contract-api
      contract-api-rest
  • contract - интеграционный модуль;
  • contract-core - модуль ядра, в нем сосредоточены описания сущности контракта, а также сервисы для работы с контрактами;
  • contract-api - модуль API, который является модулем-фасадом;
  • contract-api-rest - расширение модуля contract-api, реализует работы с API через REST.

Взаимодействие с другими сервисами

Если требуется обеспечить взаимодйествия одного сервиса с другим, то используется следующая схема:


project
  vendor
    nnx-contract
      contract
      contract-core
      contract-api
      contract-api-rest
      organization-api
      organization-api-bus

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

Такой подход отделяет API от конкретной его имплементации на базе выбранной технологии. Т.е. если сервис организаций размещен в том же приложении, что и сервис контрактов, то можно подключить модуль organization-api-db (прямая работы с базой данных), если же в другом приложение - то модуль organization-api-bus или organization-api-rest.

Общая концепция API

Сервис предоставляет API для работы с ним из других сервисов. Изначально разделяется декларативная часть API и непосредственная реализация под конкретный транспорт. Непосредственная реализация под конкретный транспорт может быть выполнена в сервисе под конкретного заказчика. Т.е. возможна такая схема:


project
  vendor
    nnx-contract
      contract
      contract-core
      contract-api
    customer-vendor
      contract-api-rest

Такие же принципы применяются для работы с API других сервисов. Т.е. на уровне абстрактного сервиса создается модуль, в котором описывается использование внешнего API, а его реализация может находиться в сервисе под конкретного заказчика:


project
  vendor
    nnx-contract
      contract
      contract-core
      contract-api
      organization-api
    customer-vendor
      contract-api-rest
      organization-api-bus

Такой подход дает возможность быть не завязанными на реализацию API, а сосредотачиваться только на его декларативной части.

Использование модулей из других сервисов

В случае если возникает потребность использовать модуль из другого сервиса, то необходимо создать модуль прокси. Например, есть сервис organization, в котором есть модуль nnx-organization/organization-core, содержащий базовый набор сущностей и сервисов для работы с организациями.

Есть сервис nnx-contract, в котором также используются организации. Предпологается, что в сервисе nnx-contract создаются свои сущности организаций и через механзмы синхронизации поддерживается актуальное состояние данных.

Для использования в сервисе nnx-contract модуля организаций создаем модуль прослойку organization


project
  vendor
    nnx-contract
      contract
      contract-core
      organization
    nnx-organization
      organization-core

В модуле nnx-contract/organization: - Регистриуется драйвер метаданных Doctrine2 для доступа к сущностям из модуля nnx-organization/organization-core в менеджере сущностей, с которым работает сервис; - Создаем интерфейс сервиса (наследуемся от аналогичного интерфейса в модуле nnx-organization/organization-core); - Реализуем фабрику для сервиса (отличие данной фабрики от аналогичной, расположенной в nnx-organization/organization-core, в том, что устанавливается другой менеджер сущностей Doctrine2); - Регистрируем сервис. В качестве имени используется созданный нами интерфейс сервиса.