Business Patterns

Um outro aspeto muito importante da framework de modelação deriva diretamente da aplicação do conceito de design pattern ao negócio, ou seja à modelação de regras específicas de negócio, do negócio de software de gestão no caso da PRIMAVERA.

Um business pattern pode ser definido como uma descrição genérica das regras utilizadas na construção de software para criar soluções para determinados problemas de negócio.

Trata-se de uma receita para um problema de negócio recorrente. E por isso será reutilizável por natureza, potenciado a velocidade de desenvolvimento das aplicações que resolvem esses problemas.

A Framework implementa e fornece um conjunto de padrões de negócio num espetro que vai desde problemas de índole mais técnica (por exemplo, como garantir a unicidade dos dados armazenados) até problemas mais complexos de índole de negócio como a reconciliação de contas ou até a contabilidade.

Alguns desses padrões são intrinsecos à plataforma, no sentido que não existe forma de fazer aplicações com ela que não os utilizem. Outros são do âmbito do produto, a sua utilização depende do produto em causa ou até a sua configuração pode ser adaptada de acordo com o produto.

Ao longo do desenvolvimento da Plataforma foram sendo identificados vários padrões, alguns dos quais ainda não estão implementados.

A imagem seguinte ilustra um catálogo dos padrões enumerados. A azul estão aqueles que a plataforma incorpora neste momento.

Business Patterns

Consideremos os seguintes exemplos para ilustrar o potencial deste conceito.

Domain Type

Os tipos de dados em software são normalmente representados pelos tipos nativos da linguagem de programação (string, int, decimal, datetime, etc.).

Na Framework os modelos de dados são definidos usando tipos de domínio (domain types) que são em si conceitos de negócio. Tais como: SmallText, Text, Number, Percentage, Email, Phone, Money, etc.

Este simples facto acrescenta conhecimento específico aos dados (um email, por exemplo, serve para enviar mensagens de email a uma entidade, seja um cliente ou outra entidade qualquer).

E, mais importante ainda, reduz drasticamente a variabilidade das aplicações na medida em que o mesmo tipo de domínio tem exatamente o mesmo tratamento em qualquer parte da aplicação e a sua tradução para os elementos nativos da linguagem de programação será feita sempre da mesma forma pelos geradores de código. Para além de reduzir a amplitude da intervenção de cada programador em particular (ele pode escolher entre SmallText, Text e LargeText mas não pode usar uma string de tamanhos diferentes indiferenciadamente).

Multi-organization e Company-dependent

Os negócios reais estão normalmente organizados em grupos de empresas relacionadas de alguma forma. Ao grupo chama-se tipicamente de organização, composta por 1 ou mais empresas.

Essas empresas partilham recursos entre si, desde os mesmos clientes e fornecedores, a, eventualmente, os mesmos armazéns, colaboradores, etc.

Qualquer entidade modelada na Framework pode ser "company-dependent", significando que está associada a uma (ou mais) das empresas da organização. No caso das entidades que não sejam company-dependent, apenas existe uma instância para todas as empresas.

Uma vez que a Plataforma está construida de raíz para suportar a execução das aplicações no contexto de uma organização e não de uma empresa particular, todas as operações de negócio do dia-a-dia podem ser realizadas indifirenciadamente para qualquer uma das empresas. Em determinado casos o utilizador estará a editar "registos" que se aplicam a todas as entidades. Noutros, terá que escolher a empresa antes de realizar determinada operação (por exemplo, criar uma encomenda). Noutros ainda terá que indicar a que empresa(s) diz respeito determinado registo (por exemplo, um cliente).

Para além dos benefícios óbvios para o utilizador da aplicação, todos os processos de negócio que envolvem a consolidação de dados entre empresas do mesmo grupo (organização) tornam-se muito mais simples de implementar, logo este padrão contribui também, ainda que mais indiretamente, para a velocidade de desenvolvimento das soluções.