Arquitetura Transacional
Nesta página é destinada a compreensão do conceito de arquitetura transacional
Atualizado
Isto foi útil?
Nesta página é destinada a compreensão do conceito de arquitetura transacional
Atualizado
Isto foi útil?
Escrito por
Antes de conceituar o que significa um sistema transacional, é necessário entender o contexto sobre os tipos de sistemas existentes e suas funções. Para isso, precisamos adentrar na teoria de sistemas da informação.
Os sistemas de informação são classificados quanto à sua funcionalidade e objetivo, atendendo à demanda dos tomadores de decisões. Eles se dividem em três tipos:
Sua funcionalidade é registrar os dados básicos referentes às transações (atividades e rotinas) da empresa. Seu objetivo é garantir que os dados sejam coletados e armazenados de forma íntegra e que haja desempenho para lidar com múltiplos acessos e transações, como inserções, exclusões e atualizações.
Sua funcionalidade é processar e distribuir informações gerenciais derivadas dos dados das operações da empresa. Seu objetivo é fornecer suporte à tomada de decisões, melhorando a eficiência e a eficácia organizacional por meio da disponibilização de informações precisas e relevantes.
Sua funcionalidade é dar suporte às decisões da empresa quanto à produtividade e excelência operacional, financeira e econômica. Esse sistema se divide em dois subtipos:
Sistemas de Apoio à Decisão (SAD): Seu objetivo é auxiliar os tomadores de decisões com informações, como modelagem de problemas, simulações e construção de cenários.
Sistemas de Apoio ao Executivo (SAE): Seu objetivo é fornecer informações detalhadas dos negócios por meio de indicadores de desempenho.
Vejamos a figura abaixo para compreender melhor a aplicação desses sistemas e suas funções.
Lembram da pirâmide DIKW? Aqui ela é aplicada juntamente com o conceito de teoria de sistemas. Um ponto a se frisar é que o sistema transacional é a “porta de entrada” e, posteriormente, com a aplicação de técnicas e tratamentos adequados, torna-se informação relevante para os tomadores de decisões.
Quando usamos o termo "tomadores de decisões", não nos referimos apenas ao executivo, mas a qualquer pessoa que precise tomar uma decisão: assistente, gerente, supervisor, analista, etc.
Desta forma, conceituamos as arquiteturas transacionais como aquelas construídas para softwares que realizam as operações da empresa. Existem diversos modelos de arquiteturas transacionais, e é comum um sistema de transações ser composto por mais de um modelo.
Como o próprio nome sugere, é mono = um. Neste modelo, há um forte acoplamento, ou seja, todas as camadas estão em um único servidor: banco de dados, aplicação (lógica de negócios) e front-end. Foi um dos primeiros modelos de arquitetura e ainda é utilizado até hoje. Como tem um forte acoplamento, qualquer mudança de tecnologia ou regra pode gerar confusão.
Esta arquitetura é muito comum para sistemas transacionais e é utilizada por grandes sistemas ERP como TOTVS e SAP. Seu princípio se baseia em um servidor onde fica a aplicação, e os demais se conectam a esse servidor. Neste modelo, o cliente não compartilha nenhum de seus recursos com o servidor, mas solicita alguma função dele, sendo o cliente responsável por iniciar a comunicação.
Neste modelo, há uma separação de camadas de aplicação denominadas de modelo, visões e controle. Essa é uma vantagem em relação ao modelo monolítico, que concentrava tudo em um único lugar. Este modelo surgiu com as primeiras linguagens de programação orientadas a objetos (POO). Seu princípio é separar a camada do usuário, aplicação e persistência de dados. A visualização (view) representa a interface gráfica para o usuário; o controle (controller) é a camada intermediária que trata e interpreta eventos e requisita dados à camada modelo; o modelo (model) contém as classes e regras que dão acesso ao banco de dados
Neste modelo arquitetural, a aplicação é construída em camadas, cada uma com suas responsabilidades, atuando de forma modular. Há um baixo acoplamento na aplicação. É comum o uso de três camadas, mas não há limite, embora mais camadas aumentem a complexidade. Um exemplo apresentada pelo Código Fonte TV para o modelo é:
Controller: Gerencia as requisições e respostas no fluxo da aplicação.
Service: Mantém as regras de negócio da aplicação.
Repository: Manipula as operações com o banco de dados.
Entity: Abstrai a tabela do banco na aplicação.
Neste modelo, o software é "quebrado" em componentes menores, conhecidos como serviços, que podem ser desenvolvidos, implantados e mantidos de forma independente. Cada serviço executa uma função específica e pode se comunicar com outros serviços conforme necessário. Uma grande vantagem dessa arquitetura é a flexibilidade na escolha das tecnologias, permitindo, por exemplo, que um serviço seja desenvolvido em Python e outro em Java.
Além disso, a SOA facilita a reutilização de serviços existentes e a integração com sistemas legados, promovendo uma maior agilidade e escalabilidade no desenvolvimento de aplicações complexas.
Essa arquitetura é parecida com a de Microsserviços, no entanto, utiliza-se um único banco, ou caso se utilize mais de um banco, este é compartilhado com todos os serviços.
Esta arquitetura é uma evolução da SOA, onde a aplicação é dividida em pequenos serviços, cada um com seu próprio banco de dados e regras de negócio. Esses serviços são independentes e comunicam-se entre si através de APIs. A principal diferença em relação à SOA é o alto grau de descentralização e independência dos serviços.
Cada microsserviço pode ser desenvolvido, implantado e escalado de forma autônoma, o que permite uma maior flexibilidade e rapidez na implementação de mudanças. Para coordenar a comunicação entre os microsserviços e gerenciar autenticação e autorização, é utilizado um API Gateway, que centraliza as requisições e garante a segurança e integridade das interações entre os serviços.
Proposta por Alistair Cockburn, a Arquitetura Hexagonal, também conhecida como Arquitetura de Portas e Adaptadores, visa desacoplar totalmente a lógica de negócio das tecnologias externas, como interfaces de usuário, bancos de dados e APIs externas.
Nesse modelo, a aplicação é estruturada em torno do domínio de negócio, que é isolado e protegido por portas (interfaces) e adaptadores (implementações). Cada porta define um contrato que pode ser implementado por um adaptador específico. Esse desacoplamento facilita a manutenção e evolução do software, permitindo que mudanças nas tecnologias externas não afetem a lógica de negócio. Além disso, promove testes mais fáceis e eficientes, uma vez que cada componente pode ser testado de forma isolada.
API - Application Program Interface
DIKW - Data, Information, Knowledge, Wisdom
ERP - Enterprise Resource Planning
MVC - Model, View e Controler
POO - Programação Orientada a Objetos
SAD - Sistema de Apoio à Decisão
SAE - Sistema de Apoio ao Executivo
SIG - Sistema de Informações Gerenciais
SOA - Service-Oriented Architecture
SPT - Sistemas de Processamento de Transações
