Концепция интеграционных модулей

Краткое описание сервисного подхода для приложений.

Приложение на zf2 рассматривается как контейнер для одного и более сервисов. В свою очередь, сервис разделяется на абстрактную часть и часть под конкретного заказчика.

Каждая из частей сервиса — это совокупность модулей, реализованных под стандарту zf2 приложения.

Важно:

  • Приложение знает о реализации сервиса под заказчика;
  • Сервис, реализованный под заказчика, знает об абстрактном сервисе и модулях, содержащих специфичный для заказчика функционал;
  • Абстрактный сервис знает об образующих его модулях;
  • Модуль не знает ни о абстрактном сервисе, ни о сервисе под заказчика, ни о приложении.

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

Абстрактный сервис и сервис, расширяющий его под конкретного заказчика

Для того чтобы определить сервис, используется специальный интеграционный модуль. Рассмотрим следующий пример:


project
  vendor
    nnx-contract
      contract
      contract-core
      contract-execution-223
      contract-api
    customer-vendor-contract
      contract
      contract-feature

Есть абстрактный сервис nnx-contract и его реализация под заказчика "customer-vendor". В примере выше, модули:

  • nnx-contract\contract
  • customer-vendor-contract\contract

будут являться интеграционными.

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

  • Приложение знает о модуле customer-vendor-contract\contract;
  • Интеграционный модуль customer-vendor-contract\contract знает о:
    • Модуле customer-vendor-contract\contract-feature;
    • Интеграционном модуле nnx-contract\contract.
  • Интеграционный модуль nnx-contract\contract знает о модулях:
    • nnx-contract\contract;
    • nnx-contract\contract-core;
    • nnx-contract\contract-execution-223;
    • nnx-contract\contract-api.

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

Работа с настройками модулей.

Расмотрим настройку модулей сервиса на примере.

Любой модуль, работающий с Doctrine2 посредством модуля DoctrineORMModule, должен знать, с каким ObjectManager'ом Doctrine2 он работает. Т.е. каждый модуль должен знать имя ObjectManager'а для работы с базой данных.

Если сервис состоит из пяти модулей, то возникает необходимость для каждого из этих пяти модулей указать значение имени ObjectManager'a.

Именно за такие настройки и отвечает интеграционный модуль. Т.е. на уровне приложения указывается имя ObjectManager'a только для интеграционного модуля заказчика.

В интеграционном модуле заказчика имя ObjectManager'a должно быть установлено всем модулям, содержащимся в сервисе под данного заказчика, а также интеграционному модулю, отвечающему за настройку абстрактной части сервиса.

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