> For the complete documentation index, see [llms.txt](https://kb.stoque.com.br/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kb.stoque.com.br/migre-para-zeev/mudancas-em-funcionalidades/camada-de-servicos.md).

# Camada de serviços

A **camada de serviços**, já disponível no BPMS3 via “feature flag” (ou seja, poderia ser ligada ou desligada), **torna-se oficial no Zeev** e passa a concentrar as **principais inovações** relativas a execuções de processos daqui para frente.

A **camada de serviços pode ser interpretada** como uma camada de configuração adicional entre o usuário final e o fluxograma automatizado do processo.

Ela permite, em primeira instância, que um processo seja compreendido como a “espinha dorsal” de uma solicitação e a base para não um , mas vários serviços. Com isso, a organização pode mapear e modelar processos que representem regras genéricas de workflow e reutilizá-las em dezenas de serviços diferentes.

É importante destacar, também, que a camada de serviços reforça **a necessidade de proteger e isolar o processo**. O processo possui **regras internalizadas** que devem ser modificadas com **controle e governança**. Observamos muitas instalações onde há um uso indiscriminado da administração e manutenção de processos em tempo real, o que não tão incomum gera problemas em execução de processos em produção.

A orientação do Zeev daqui em diante é **restringir cada vez mais a modificação de processos** em tempo real, trazendo essa responsabilidade para a **camada de serviços**, que funciona como uma “máscara” de configuração para o processo.

Por isso, apesar de o sistema permitir que usuários solicitem tanto serviços quanto processos diretamente (variando conforme as permissões de acesso), recomendaremos cada vez mais que **mesmo processos específicos e especializados tenham um serviço associado**, e que os usuários interagem com o serviço, e não com o processo. Não descartamos que isso se torne obrigatório em releases futuros, fazendo-se despublicar todos os processos.

Nesse caminho, **novos recursos** que antes estariam vinculados a processo estarão, cada vez mais, **vinculados a serviços**.

##
