Separar a lógica do processo de negócio
July 15, 2008 – 2:17 pm by Gustavo S. SinisPromover uma cultura de processo é um dos fundamentos da adoção de SOA.
Em geral, os processos de negócio concentram-se nas tarefas repetitivas executadas em uma seqüência lógica (fluxos), fornecendo resultados definidos para apoiar os objetivos da organização. As tarefas buscam atingir alguma meta atômica, freqüentemente utilizando como entrada ou saída produtos de trabalho. Os processos podem ser classificados como: a) principal, para os processos de negócio que fornecem valor para atores externos da empresa como, por exemplo, clientes; b) administrativo, para os processos de negócio que fornecem a valor para atores internos da empresa; c) apoio, para os processos de negócio que apóiam os processos principais.
Freqüentemente, os processos são utilizados sem considerar explicitamente os fluxos de trabalho do negócio (seqüência lógica das tarefas do processo), utilizando apenas os conceitos principais extraídos do negócio. A isto dá-se o nome de modelagem de domínio de negócio, que são conceitos obtidos a partir da análise dos produtos de trabalho e do vocabulário utilizado no processo relevante ao software que está sendo desenvolvido. Tais conceitos são utilizados como um vocabulário comum para OOAD.
Para ilustrar uma abordagem tradicional, focando em práticas, podemos relacionar de forma sintética algumas atividades.
Na iteração temos:
- processo de negócio é modelado ou entendido e, em muitos casos, já está modelado previamente (BPMN);
- em função das necessidades de automação ou alteração do processo (ou seja, os requisitos), soluções funcionais são detalhadas (UC essencial [1], historias, TDD);
- na realização dos UCs, os POJOS, representando o modelo de domínio da aplicação (MDD), recebem responsabilidades e trocam mensagens para atender as necessidades dos UCs (Cartões CRC [1], diagrama de robustez [1], GRASP, DDD);
Nesta abordagem, como mais de um UC pode ser realizado em paralelo, equipes colaborativas são indispensáveis. É comum existir uma pessoa responsável pelo merge dos objetos/conceitos que estão sendo trabalhados em paralelo, pois UCs podem compartilhar esses conceitos (Domínio). Em corporações mais complexas, existem sistemas que também compartilham conceitos; com isso, em muitos casos, as regras de negócio são duplicadas ou integrações spaghetti são usadas. Para controlar a complexidade, uma estratégia de decomposição de domínio pode ajudar, pois a abordagem facilita o reaproveitamento do domínio criando módulos coesos e pouco acoplados.
O processo é considerado, mas o fluxo do processo fica dentro da aplicação misturado com: lógica do domínio, pré-condições dos componentes de negócio ou, ainda, fica por conta da disciplina dos usuários ou de gerentes de áreas. O problema reside em considerar apenas o domínio, sem separar o fluxo do negócio, pois o processo de negócio é uma forma natural de entender como uma corporação funciona. Práticas de BPM como, por exemplo, monitoração de instâncias de processos, análise de tendência e simulação, podem provocar mudanças em processos de negócio. Separar a lógica do processo proporciona flexibilidade, que é um diferencial estratégico.
Serviços de processo - uma abstração que representa uma atividade do processo - auxiliam na separação da lógica do processo de negócio da lógica do domínio, fornecendo uma interface bem definida e independente, que organiza a aplicação para apoiar processos. Serviços são orquestrados (lógica de processo de negócio) para executar o processo, e o padrão de mercado atual utilizado é o BPEL.
Existem também abordagens em que serviços representam partes de um processo ou subprocessos, não apenas uma tarefa. Neste caso, o serviço possui o estado do processo, representa um conjunto de tarefas e a seqüência de execução. Atualmente, implementações BPMS e BEPL substituem com vantagens essa abordagem.
Mesmo que a aplicação não tenha uma abordagem BPM (BPMS +BPEL), serviços de processo são úteis, pois orientam a arquitetura, fornecem um vocabulário comum entre o processo de negócio e a aplicação, facilitando também a comunicação da TI com as áreas de negócio. Técnicas de decomposição de processos ajudam a identificar os serviços candidatos, uma vez que a existência desse serviço de processo só faz sentido se o mesmo estiver associado a uma atividade no processo de negócio.
Para auxiliar na separação da lógica do processo, algumas atividades devem ser incluídas no desenvolvimento como, por exemplo, a identificação de serviços. Na identificação de serviços candidatos, podemos relacionar as seguintes técnicas: a decomposição de processos, ou seja, a identificação de serviços de processo de negócio; e a decomposição de domínio, isto é, a identificação de serviços básicos.
Taxonomia instanciada
Serviços de processos são executados em uma seqüência lógica, e essa seqüência pode ser criada em BPEL ou em uma camada específica para a lógica de processo. Esses serviços, a fim de cumprir uma tarefa do processo de negócio, orquestram um ou mais serviços básicos.
Serviços básicos de negócio encapsulam a lógica de domínio e a expõem através de interfaces bem definidas. No mesmo sistema, podemos ter mais de um serviço básico; neste caso, eles são identificados a partir da aplicação de técnicas de decomposição de domínio. Um serviço básico pode, ainda, representar um sistema legado inteiro. Serviços básicos são criados para atender as necessidades dos UC, mas sua interface deve ser projetada para ser reutilizável corporativamente.
Eventualmente, para atender um UC, temos códigos que não pertencem exclusivamente a um serviço básico (seqüência de execução), e também não estão coesos/associados diretamente a um serviço de processo. Neste caso, se o código for reutilizável, podemos usar o conceito de serviço composto, que é um serviço básico que orquestra outros serviços básicos, funcionando como um camada de indireção, ou seja, evitando que serviços básicos troquem mensagens diretamente (baixo acoplamento).
Clientes dos serviços de processo são responsáveis pela lógica de processo (BPMS ou aplicações); clientes dos serviços básicos são responsáveis por garantir a pré-condição e a seqüencia de execução (Serviços compostos ou aplicações); serviços básicos encapsulam regras de negócio.
———————————————————————-
[1] Scott W. Ambler
