Magento 2: ¿Qué es un contrato de servicio?

En Magento 2, ¿hay un ejemplo concreto de algo que se construye utilizando el concepto de Contrato de servicio ? He visto mucho este término, pero al mirar Magento 2 tal como existe ahora no me queda claro si los contratos de servicio son principios más orientadores, o si realmente se vinculan a implementaciones específicas de cosas en Magento 2.

Según tengo entendido, todas las interfaces definidas en la carpeta Api son los contratos de servicio. Entonces, en cualquier lugar donde se use la interfaz en lugar de la implementación real de la clase, usa el Contrato de servicio.

Un ejemplo sería la implementación de este complemento aquí https://github.com/magento/magento2/blob/2.3.2/app/code/Magento/GiftMessage/Model/Plugin/OrderGet.php#L78

Usa

protected function getOrderGiftMessage(\Magento\Sales\Api\Data\OrderInterface $order)

en lugar de \Magento\Sales\Model\Order

Los servicios (también llamados contratos de servicio) son uno de nuestros patrones de desarrollo principales en Magento 2 para garantizar interfaces estables para una fácil personalización / extensión. Toman 2 formas en la base del código (ambas están anotadas con@api en la clase o en los métodos de clase para identificarlos como interfaces estables que puede personalizar o exponer como una API web): API o SPI. Las API se definen en la carpeta API y toman dos formas: un servicio totalmente refactorizado y solo un módulo solo API.

Los servicios totalmente refactorizados se reflejan en los módulos Cliente, Inventario, Impuestos y Cotización * (el Cliente es el servicio a emular, Cotización tiene áreas restantes que deben ser refactorizadas). Un módulo solo de API se puede ver en Catálogo, Ventas y CMS. Para servicios totalmente refactorizados, solo debe hacer un complemento en el método de servicio para afectar tanto las API web como la GUI. Para los módulos solo de API, necesitaría agregar un método de servicio para afectar las API web, pero aún necesitaría hacer personalizaciones de estilo 1x para afectar la GUI.

Los SPI son básicamente interfaces dentro del código anotado con los @apilugares previstos que terceros implementarían para proporcionar alguna funcionalidad comercial. Un ejemplo de un SPI ( CarrierInterface) definido en el módulo de envío que implementaría en su módulo de envío (es decir, Ups).

El marco de servicio ofrece una serie de ventajas interesantes. Fácil exposición como una API web (y próxima publicación 2.0 a través de colas de mensajes) vi webapi.xmlconfiguración (como estilo SOAP y REST). En el corto plazo (post 2.0) agregaremos llamadas de API (llamadas de sincronización o Webhooks si está configurado para disparar asíncrona, mensajes salientes) que se pueden administrar / exponer a través de la configuración. Instalación / actualizaciones más seguras: puede identificar mediante programación situaciones problemáticas (2 o más extensiones que implementan la misma interfaz). Personalización optimizada que afecta tanto a las aplicaciones web como a las interfaces gráficas de usuario, ya que solo hay un método / servicio para personalizar (para módulos completamente refactorizados o nuevos módulos / servicios creados por la comunidad).

Verifique los usos de estos métodos:

• \Magento\Customer\Api\AccountManagementInterface::createAccount
• \Magento\Customer\Api\CustomerRepositoryInterface::getById

Contratos de servicio de Magento

Esencialmente, los contratos de servicio son solo un conjunto de interfaces y clases que protegen la integridad de los datos y ocultan la lógica empresarial. La razón por la cual los clientes querrán usar esto es que el contrato permite que el servicio evolucione sin afectar a sus usuarios.

La razón por la cual esta actualización es importante es porque cambia la forma en que los usuarios interactúan con diferentes módulos. En Magento 1, no había buenas formas de interactuar con otros módulos. Con los contratos de servicio en Magento 2, puede acceder y manipular datos fácilmente, sin tener que preocuparse por la estructura del sistema.

Arquitectura de contrato de servicio

La capa de servicio tiene dos tipos de interfaz diferentes: interfaces de datos e interfaces de servicio. Las interfaces de datos son objetos que preservan la integridad de los datos mediante el uso de los siguientes patrones:

They’re read-only, since they only define constants and getters.
Getter functions can contain no parameters.
A getter function can only return a simple object type (string, integer, Boolean), a simple type array, and another data interface.
Mixed types can’t be returned by getter functions.
Data entity builders are the only way to populate and modify data interfaces.

Las interfaces de servicio proporcionan un conjunto de métodos públicos que un cliente puede usar. Hay tres subtipos de interfaces de servicio:

Repository Interfaces
Management Interfaces
Metadata Interfaces

Interfaces de repositorio

Las interfaces de repositorio aseguran que un usuario pueda acceder a entidades de datos persistentes. Por ejemplo, las entidades de datos persistentes dentro del Módulo del cliente son Consumidor, Dirección y Grupo. Esto nos da tres interfaces diferentes:

CustomerRepositoryInterface
AddressRepositoryInterface
GroupRepositoryInterface

Los métodos que tienen estas interfaces son:

Save – If there’s no ID, creates a new record, and updates what’s existing if there is one.
Get – Looks for the IDs in the database and returns a certain data entity interface.
GetList – Finds all data entities that correspond with the search criteria, then gives access to the matches by returning the search result interface.
Delete – Deletes the selected entity
DeleteById – Deletes the entity when you only have its key.

Interfaces de gestión

Estas interfaces contienen diferentes funciones de administración que no están relacionadas con los repositorios. Aquí hay unos ejemplos:

AccountManagementInterface contains functions such as createAccount(), isEmailAvailable(), changePassword(), and activate().
AddressManagementInterface checks whether an address is valid by using the validate() function.

El número de patrones crece constantemente y, a medida que lo hace, es probable que se les agreguen algunas de estas funciones.

Interfaces de metadatos

Las interfaces de metadatos proporcionan información sobre todos los atributos definidos para una entidad específica. Esto también incluye atributos personalizados, a los que puede acceder con la función getCustomAttribute ($ name). Estos atributos personalizados incluyen:

EAV attributes – Defined via the administration interface for a local site. They can differ according to the site, which means that they can’t be represented in the data entity interface written in PHP.
Extension attributes, for which the extension modules are used.

Referencia:

https://www.interactivated.me/uk/blog/service-contracts-magento-2/