Magento 2: O que é um contrato de serviço

No Magento 2, existe um exemplo concreto de algo criado usando o conceito de Contrato de Serviço ? Eu já vi esse termo muito, mas olhando para o Magento 2 como ele existe agora, não está claro para mim se os Contratos de Serviço são mais princípios orientadores ou se eles realmente se ligam a implementações específicas das coisas no Magento 2.

Pelo que entendi, todas as interfaces definidas na pasta Api são os Contratos de Serviço. Portanto, em qualquer lugar em que a interface seja usada, em vez da implementação real da classe, ela usa o Contrato de Serviço.

Um exemplo seria a implementação deste plugin aqui 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)

ao invés de \Magento\Sales\Model\Order

Serviços (também chamados de contratos de serviço) são um dos nossos principais padrões de desenvolvimento no Magento 2 para garantir interfaces estáveis ​​para fácil personalização / extensão. Eles assumem 2 formulários na base de código (ambos são anotados @apinos métodos de classe ou classe para identificá-los como interfaces estáveis ​​que você pode personalizar e ou expor como uma API da web): API ou SPI. As APIs são definidas na pasta API e assumem dois formulários - um serviço totalmente refatorado e apenas um módulo somente API.

Os serviços totalmente refatorados são refletidos nos módulos Cliente, Estoque, Impostos e Cotação * (o Cliente é o serviço a ser copiado, o Cotação possui áreas remanescentes que precisam ser refatoradas). Um módulo somente API pode ser visto em Catálogo, Vendas e CMS. Para serviços totalmente refatorados, você só precisa fazer um plug-in no método de serviço para impactar as APIs da web e a GUI. Para módulos apenas da API, você precisaria fazer o plug-in no método de serviço para impactar APIs da Web, mas ainda precisaria fazer personalizações de estilo 1x para impactar a GUI.

SPIs são basicamente interfaces no código anotado com @apipontos pretendidos que terceiros implementariam para fornecer alguma funcionalidade comercial. Um exemplo de SPI ( CarrierInterface) definido no módulo Remessa que você implementaria em seu módulo de remessa (por exemplo, Ups).

A estrutura de serviço oferece várias vantagens interessantes. Fácil exposição como uma API da Web (e publicação posterior 2.0 através de filas de mensagens) vi webapi.xmlconfiguração (no estilo SOAP e REST). No curto prazo (pós 2.0), adicionaremos chamadas de API (chamadas de sincronização ou Webhooks se configuradas para disparar assíncronas, saída de mensagens) que podem ser gerenciadas / expostas por meio da configuração. Instalação / atualização mais segura - você pode identificar programaticamente situações problemáticas (2 ou mais extensões implementando a mesma interface). Personalização simplificada que afeta as APIs da Web e a GUI, pois há apenas um método / serviço para personalizar (para módulo totalmente refatorado ou novos módulos / serviços criados pela comunidade).

Verifique o uso destes métodos:

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

Contratos de serviço Magento

Essencialmente, os contratos de serviço são apenas um conjunto de interfaces e classes que protegem a integridade dos dados e ocultam a lógica de negócios. A razão pela qual os clientes desejam usar isso é que o contrato permite que o serviço evolua sem afetar seus usuários.

A razão pela qual essa atualização é importante é porque ela altera a maneira como os usuários interagem com diferentes módulos. No Magento 1, não havia boas maneiras de interagir com outros módulos. Com os contratos de serviço no Magento 2, você pode acessar e manipular dados facilmente, sem ter que se preocupar com a estrutura do sistema.

Arquitetura de contrato de serviço

A camada de serviço possui dois tipos de interface diferentes: Interfaces de dados e Interfaces de serviço. Interfaces de dados são objetos que preservam a integridade dos dados usando os seguintes padrões:

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.

As interfaces de serviço fornecem um conjunto de métodos públicos que um cliente pode usar. Existem três subtipos de interfaces de serviço:

Repository Interfaces
Management Interfaces
Metadata Interfaces

Interfaces de repositório

As interfaces de repositório garantem que um usuário possa acessar entidades de dados persistentes. Por exemplo, entidades de dados persistentes no Módulo Cliente são Consumidor, Endereço e Grupo. Isso nos dá três interfaces diferentes:

CustomerRepositoryInterface
AddressRepositoryInterface
GroupRepositoryInterface

Os métodos que essas interfaces possuem são:

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 gerenciamento

Essas interfaces contêm funções de gerenciamento diferentes que não são relacionadas aos repositórios. aqui estão alguns exemplos:

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

O número de padrões está em constante crescimento e, ao fazê-lo, é provável que algumas dessas funções sejam adicionadas a eles.

Interfaces de metadados

As interfaces de metadados fornecem informações sobre todos os atributos definidos para uma entidade específica. Isso também inclui atributos customizados, que você pode acessar com a função getCustomAttribute ($ name). Esses atributos personalizados incluem:

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.

Referência:

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