Tópicos principais:
- O propósito da modelagem de domínio nas aplicações de grande porte é apoiar as operações do negócio;
- As operações do negócio precisam de uma trilha de evidências para os processos de negócio;
- Um modelo de domínio que apoie a operação do negócio deve ser baseado em objetos momento-intervalo que representam as trilhas da evolução do negócio;
- Outros objetos do domínio (entidades, papéis, descrições) podem ser derivados dos objetos momento-intervalo;
- Tipos diferentes de objetos do domínio podem ser representados com cores diferentes para melhor visualização.
Há muitos métodos para modelar domínios, e para o mesmo domínio podem ser produzidos modelos diferentes, aplicando abordagens diferentes de modelagem. Ouço então, frequentemente, a pergunta: como garantir que o processo de modelagem está correto?
Parece uma pergunta simples. Mas pode ser mais complicada do que esperamos. Primeiro, temos que deixar claro qual é o objetivo da modelagem. Se for apenas para descrever problemas, então não há modelagem certa ou errada, só diferenças que provêm dos vários pontos de vista e perspectivas. No entanto, se estamos falando de modelar o sistema de negócio de uma empresa, aí a pergunta deveria ser: "Como podemos garantir que o modelo pode corresponder às operações de uma empresa?"
Uma resposta simples para esta pergunta pode ser feita por meio de um exemplo:
Antes de realizar a análise e modelagem, devemos saber qual é o propósito de um sistema de negócio para a empresa. Geralmente, o propósito é mais relevante para as necessidades de quem toma as decisões ou dos gestores.
Agora, se coloque na posição de um diretor de operações de um loja de eBooks online. Um belo dia, um cliente reclama da falta de um livro que comprou e que preço total está errado, pois ele afirma que pagou a mais. Antes de se comprometer a resolver este problema, primeiro é necessário verificar se o que o cliente disse é verdade. Para fazer isso, e decidir com precisão, qual informação é necessária?
De forma simples, identifique quais livros foram pedidos e quanto foi pago pelo cliente, e ainda quais livros foram de fato entregues pela loja. Infelizmente, devido a limites da tecnologia, não é possível identificar o que ocorreu. Mas felizmente, não é necessário fazer isso; é possível obter a informação verificando o pedido do cliente, o registro da transação em seu banco eletrônico, e o comprovante de entrega expressa pelo correio.
Verificando o pedido e o comprovante do correio foi possível descobrir que o cliente fez o pedido há três dias, e a loja enviou os livros anteontem. Também foi verificado no pedido que o cliente comprou sete livros ao todo, mas no comprovante só constam endereço, número da entrega, frete e peso, mas nenhuma informação sobre os livros. Agora é necessário pedir mais detalhes ao departamento de expedição.
A expedição manda os detalhes sobre o pacote a partir do número da entrega, e com certeza há somente seis livros. Além disso, chega a seu conhecimento que há um pedido para entrega separada, indicando que devido a falta de um livro no estoque, o livro do cliente será preparado para envio.
Então, o que falta acertar é o pagamento. No registro bancario, o cliente pagou um total de 132,50 sem contar o correio. O total que aparece no pedido também é 132,50, o que mostra claramente que o cliente não pagou a mais.
Para certificar-se que tudo foi feito corretamente, selecione os sete livros no site para ver se os preços estão ou não corretos. Surpreendentemente, o total é somente 128,30. Depois de verificar cuidadosamente, descobriu-se que um dos livros está agora em promoção. Agora, o problema é saber quando começou a promoção?
O departamento de marketing tem um plano de ofertas, e o livro em questão está em promoção desde ontem. Isto é, o cliente fez o pedido antes da promoção começar.
Portanto o melhor a fazer é ligar para o cliente e se desculpar, explicar o preço dos livros e a promoção.
Será que isso não é demais para um diretor de operações? Este exemplo é uma ficção, mas o que podemos aprender com esta história?
Todo evento em um negócio deveria deixar trilhas em forma de dados. Trilhas de eventos podem ser feitas acompanhando as trilhas dos dados. Assim como descrito nesta história, não é possível voltar ao passado para saber o que aconteceu, mas, usando recibos e comprovante, é possível determinar o que aconteceu até certo ponto. Então, colocando os dados em ordem cronológica, podemos saber o que ocorreu num determinado período.
Por que a cadeia de evidência formada pelos dados nos ajuda a compôr a trilha de uma operação do negócio?
Porque os dados não foram escolhidos ao acaso. Revendo o processo todo, primeiro selecionamos o pedido e o comprovante de entrega. Se o cliente cometeu um erro ao colocar o pedido e o comprovante mostrar que foram enviados sete livros, então não há responsabilidade por omissão. O pedido e o comprovante são de fato a base para responsabilidade legal da empresa.
Depois de confirmada a responsabilidade legal da empresa, verificou-se o resultado da execução do processo de expedição, para saber se o resultado da execução de um processo de negócio principal está correto. Em outras palavras, estes dados foram resultados da execução de processos importantes do seu sistema de negócio.
Os dados resultantes da execução dos processos nos ajudam a acompanhar e analisar alguns eventos sem entrar nos detalhes do processo.
Não somente no caso do exemplo extremo, como mostrado no exemplo anterior, mas também em qualquer transação econômica normal, precisamos ter clareza quanto às seguintes questões:
- Se paguei uma soma de dinheiro, quais são meus direitos?
- Se recebi uma soma de dinheiro, quais são minhas obrigações?
Estas perguntas só podem ser respondidas se as trilhas correspondentes forem capturadas pelo sistema de negócio. Portanto, um dos propósitos principais de um sistema para empresa é de registrar as trilhas e usá-las como uma cadeia de evidências válida.
Mudemos agora perspectiva para um provedor de serviços de TI profissional. Para construir uma cadeia de evidências válida em um sistema de TI, como analista de negócio, é necessário saber quais eventos devem ser registrados e quais trilhas devem ser registradas por estes eventos.
Em geral estas trilhas possuem uma característica comum interessante: são momentos-intervalos. Determinar estes momentos-intervalos é o primeiro passo na modelagem. Organizando um pouco os momentos-intervalos temos a espinha dorsal do modelo completo do domínio:
Determinada a espinha dorsal, devemos enriquecer o modelo, fazendo com que descreva melhor os conceitos do negócio. A esta altura, devemos completar o modelo com algumas entidades. Entidades são objetos operando ou sendo operados durante momentos-intervalos, ou lugares em que acontecem momentos-intervalos. Há portanto três tipos de entidades: fato/lugar/coisa.
Podemos, com base nisso, explorar melhor como estas entidades estão envolvidas nos vários processos. Para isso, serão necessários papéis, porque em alguns casos um tipo de entidade pode ter papéis diferentes em diferentes processos. Por exemplo, no diagrama a seguir, a entidade Funcionário pode ser Distribuidor ou Diretor de Marketing em cenários diferentes:
Por fim, podemos colocar mais informações detalhadas sobre as entidades na descrição dos objetos. Por exemplo, no modelo do domínio mostrado no diagrama a seguir, o objeto Livro poderia conter informação limitada e fundamental sobre um livro, como título e ISBN, enquanto outra informação descritiva do livro (autor, resumo, índice, etc.) por ser colocada em um objeto Descrição do Livro.
Até agora obtivemos um modelo do domínio aplicando a técnica de "modelagem de objetos em cores". Estas cores foram sugeridas inicialmente por Peter Coad e outros em seu livro "Java Modeling In Color With UML". Rosa para os momentos-intervalo, verde para entidades (fato/lugar/coisa), amarelo para papéis e azul para descrições.
Revisando brevemente este processo, não é difícil encontrar a ordem e os pontos chave desta técnica de modelagem.
- Identifique eventos que devem ser registrados baseado nas demandas que vêm dos gestores e da operação;
- Identifique trilhas e os objetos momentos-intervalos correspondentes que podem representar os eventos que devem ser registrados;
- Identifique as entidades (fato/lugar/coisa) relacionadas aos objetos momento-intervalo;
- Para entidades que podem ter diferentes papéis (frequentemente fatos que representam pessoas), extrair o objeto papel para cada papel;
- Por fim, acrescente as informações da entidade na descrição dos objetos.
No primeiro passo, tomamos os objetivos dos gestores e da operação como ponto de partida do processo de modelagem. Portanto, o modelo do domínio todo é de fato estabelecido em torno da questão "o quanto estas trilhas devem ser efetivas". Um modelo destes será capaz de suportar a operação do negócio.
Sobre o Autor
Xu Hao, CTO e Consultor Principal da ThoughtWorks China e membro do Technology Advisory Board da ThoughWorks. Também fundador do BJUG (Grupo de usuários Java de Pequim) e do AgileChina.