Arquitetura de Sistemas da Informação

Padrões de Projeto (GoF, de criação, estruturais, comportamentais).

Design Patterns (Padrões de Projeto) são soluções reutilizáveis para problemas recorrentes no design de software. Eles representam um conjunto de práticas testadas e comprovadas que ajudam os desenvolvedores a resolver desafios complexos de maneira eficiente, promovendo a modularidade, flexibilidade e manutenibilidade do código.

Os Padrões de Projeto foram formalizados e catalogados por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, conhecidos como “Gang of Four” (GoF), em seu livro “Design Patterns: Elements of Reusable Object-Oriented Software”. Esses padrões são divididos em três categorias principais: de criação, estruturais e comportamentais.

1. Padrões de Criação: Estes padrões tratam da criação de objetos de forma eficiente, ocultando a complexidade da instânciação e permitindo que o sistema seja flexível quanto às classes concretas usadas.
   • Exemplos: Factory Method, Abstract Factory, Singleton, Builder, Prototype.
2. Padrões Estruturais: Esses padrões lidam com a composição de classes e objetos para formar estruturas maiores e mais complexas.
   • Exemplos: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy.
3. Padrões Comportamentais: Esses padrões focam nas interações entre objetos e como eles colaboram para realizar tarefas.
   • Exemplos: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor.

Os Padrões de Projeto oferecem vários benefícios:

• Reutilização de Código: Ao aplicar padrões, é possível reutilizar soluções já estabelecidas, economizando tempo e esforço.
• Comunicação Comum: Padrões fornecem um vocabulário comum para a equipe de desenvolvimento, facilitando a comunicação e compreensão.
• Flexibilidade: Os padrões promovem um design flexível que permite alterações e expansões futuras com menor impacto.

No entanto, é importante reconhecer que não existe uma abordagem única para todos os problemas. A escolha de um padrão deve ser baseada na compreensão profunda do problema e nos requisitos específicos do projeto. Além disso, é fundamental estar ciente de que, embora os Padrões de Projeto sejam valiosos, seu uso excessivo ou inadequado pode levar a um código complexo e difícil de manter.

Padrões GRASP (controller, expert)

Os padrões GRASP (General Responsibility Assignment Software Patterns) são diretrizes que auxiliam na atribuição de responsabilidades de classes e objetos em um sistema orientado a objetos. Dois desses padrões são o Controller e o Expert, que desempenham papéis fundamentais no design eficaz de software.

O padrão Controller visa gerenciar o fluxo de interações entre os elementos do sistema. Ele atua como um ponto central que recebe as solicitações e direciona-as para as partes apropriadas do sistema. Isso resulta em uma separação clara das responsabilidades, evitando que as classes se tornem excessivamente acopladas e facilitando a manutenção e expansão do sistema. O Controller é frequentemente usado em sistemas baseados em interfaces de usuário, onde lida com a entrada do usuário e coordena ações subsequentes.

Por outro lado, o padrão Expert busca atribuir responsabilidades às classes que possuem o conhecimento necessário para executá-las. Isso promove o princípio do encapsulamento, onde as informações e operações relacionadas são agrupadas em uma única classe. O Expert ajuda a evitar o acoplamento excessivo, pois reduz a necessidade de colaboração entre diferentes classes para realizar uma tarefa específica. Além disso, ele melhora a coesão das classes, tornando-as mais focadas e especializadas em suas funções.

Em resumo, os padrões GRASP proporcionam uma abordagem sistemática para atribuir responsabilidades de maneira eficiente em sistemas orientados a objetos. O Controller centraliza o controle e direcionamento das interações, enquanto o Expert coloca a responsabilidade nas mãos das classes que possuem o conhecimento apropriado. Integrar esses padrões ao design de software resulta em sistemas mais organizados, flexíveis e de fácil manutenção.

Arquiteturas em camadas, baseada em serviços, microsserviços, orientação a eventos, cliente-servidor, serverless.

As arquiteturas de software desempenham um papel crucial na construção de sistemas eficientes, escaláveis e modularizados. Dentre as diversas abordagens arquiteturais, algumas se destacam pelo seu impacto no desenvolvimento de soluções tecnológicas. Vamos explorar algumas delas:

1. Arquiteturas em Camadas: Nesse modelo, o sistema é dividido em camadas distintas, cada uma com responsabilidades específicas. A separação em camadas, como a de apresentação, lógica de negócios e persistência de dados, ajuda a modularizar o sistema, simplificando a manutenção e a evolução.
2. Arquitetura Baseada em Serviços (SOA): Essa abordagem enfatiza a criação de serviços independentes que podem ser combinados para formar um sistema coeso. Cada serviço oferece funcionalidades específicas, com comunicação geralmente ocorrendo por meio de APIs. Isso promove a reutilização de serviços e facilita a integração entre sistemas heterogêneos.
3. Microsserviços: Uma extensão da arquitetura baseada em serviços, os microsserviços dividem o sistema em componentes ainda menores e independentes. Cada microsserviço é responsável por uma funcionalidade única, o que permite escalabilidade independente e manutenção mais granular.
4. Orientação a Eventos: Nesse modelo, os componentes do sistema se comunicam por meio de eventos assíncronos. Quando um evento ocorre, outros componentes são notificados e podem reagir conforme necessário. Isso promove um acoplamento mais fraco e permite a construção de sistemas flexíveis e reativos.
5. Cliente-Servidor: Essa é uma das arquiteturas mais tradicionais, onde o sistema é dividido em duas partes: o cliente, que solicita serviços, e o servidor, que fornece esses serviços. Isso permite a distribuição das responsabilidades e é amplamente utilizado em aplicações web.
6. Serverless: Uma abordagem emergente, onde o desenvolvedor foca apenas no código do aplicativo, sem se preocupar com a infraestrutura subjacente. Plataformas de computação serverless gerenciam automaticamente a escalabilidade e a alocação de recursos.

Cada uma dessas arquiteturas possui vantagens e desafios específicos. A escolha depende das necessidades do projeto, escalabilidade, eficiência e capacidade de manutenção. Uma compreensão profunda de cada modelo é essencial para escolher a abordagem mais adequada e projetar sistemas que atendam aos requisitos do negócio de maneira eficaz.

Arquitetura hexagonal

A Arquitetura Hexagonal, também conhecida como Arquitetura Ports and Adapters, é um modelo arquitetural que busca separar a lógica de negócios central do sistema das dependências externas, como interfaces de usuário, bancos de dados e serviços externos. Essa abordagem visa criar sistemas mais flexíveis, testáveis e independentes de tecnologias externas.

Na Arquitetura Hexagonal, o núcleo do sistema, que contém a lógica de negócios, é representado pelo hexágono interno. Ele é independente das implementações externas e define as regras de negócios sem se preocupar com detalhes de interface ou armazenamento de dados.

As principais características da Arquitetura Hexagonal são:

1. Separação de Camadas: A arquitetura é dividida em três camadas principais: a camada de domínio (ou de aplicação), a camada de interfaces e a camada de infraestrutura.
2. Portas e Adaptadores: As portas (ports) são interfaces definidas no hexágono interno para permitir que os componentes externos interajam com o núcleo. Os adaptadores (adapters) implementam essas portas, conectando o núcleo às tecnologias externas.
3. Independência Tecnológica: O hexágono interno não depende de implementações específicas externas, o que facilita a substituição de componentes sem afetar a lógica de negócios.
4. Testabilidade: A separação das camadas e a dependência em relação a interfaces facilitam a realização de testes de unidade, pois é possível isolar o núcleo do sistema de suas dependências externas.
5. Mudanças Controladas: As mudanças na lógica de negócios não afetam diretamente as implementações externas, garantindo uma maior estabilidade do sistema.

A Arquitetura Hexagonal é especialmente adequada para sistemas complexos em que a lógica de negócios é crítica e precisa ser flexível para acomodar mudanças. Ela ajuda a evitar acoplamentos indesejados entre as partes do sistema e permite que o desenvolvimento ocorra de maneira mais ágil e segura.

Em resumo, a Arquitetura Hexagonal é uma abordagem que visa a separação clara das preocupações, com um foco específico na lógica de negócios. Isso resulta em sistemas mais coesos, testáveis e flexíveis, capazes de se adaptar às mudanças do ambiente tecnológico e das necessidades do negócio.

Anti-padrões arquiteturais.

Anti-padrões arquiteturais, também conhecidos como “Padrões de Projeto de Má Prática” ou “Padrões de Projeto Não Recomendados”, são soluções ineficientes, inadequadas ou problemáticas para desafios comuns no design de software. Enquanto os padrões de design visam promover boas práticas e soluções reutilizáveis, os anti-padrões alertam para abordagens que podem levar a sistemas de baixa qualidade, difícil manutenção e problemas de escalabilidade. Eles servem como um guia para identificar e evitar armadilhas comuns no desenvolvimento de software.

Alguns exemplos de anti-padrões arquiteturais incluem:

1. Bola de Lama (Big Ball of Mud): Refere-se a sistemas desorganizados, onde a estrutura é confusa e as responsabilidades estão misturadas. Falta de modularidade e falta de separação de preocupações são características desse anti-padrão.
2. Deus Objeto (God Object): Caracterizado por um objeto centralizado que possui muitas responsabilidades e interações com outras partes do sistema. Isso leva a um alto acoplamento e dificulta a manutenção.
3. Acoplamento de Dados (Data Coupling): Representa uma situação onde as partes do sistema estão fortemente acopladas por meio do compartilhamento excessivo de dados. Isso torna difícil a manutenção e a evolução.
4. Abstração Prematura: Criar camadas de abstração desnecessárias antes de entender completamente os requisitos do sistema, levando a complexidade desnecessária e dificultando a implementação real.
5. Modelo Anêmico: Caracterizado por classes que possuem apenas dados, mas nenhuma lógica associada. Isso resulta em lógica dispersa pelo sistema, dificultando a manutenção e testes.
6. Código Espaguete (Spaghetti Code): Refere-se a um código desorganizado, onde as instruções estão entrelaçadas e difíceis de seguir. Isso resulta em dificuldades na depuração e manutenção.
7. Conflito de Interesses (Conflicting Interests): Ocorre quando as decisões de design são baseadas em preferências pessoais ou políticas em vez de critérios técnicos ou de negócios.

O reconhecimento dos anti-padrões arquiteturais é fundamental para evitar armadilhas no desenvolvimento de software. Identificá-los precocemente ajuda a tomar decisões mais informadas e a optar por soluções que promovam a qualidade, escalabilidade e manutenção eficiente do sistema.

^{*Atualizado em 28 de agosto de 2023}