DEV Community: Gabriel Alcara

# 5 Estudos: Qual a diferença entre arquitetura de software e design de software?

Gabriel Alcara — Wed, 06 Mar 2024 02:16:43 +0000

Quando usamos esses termos pode parecer que se tratam da mesma coisa, mas fazendo uma analogia ao mundo real, podemos entender melhor essas diferenças.

Imagine que você é um arquiteto encarregado de projetar um prédio. Sua responsabilidade é criar o plano geral do edifício, decidindo quantos andares terá, onde estarão os elevadores e escadas, como será a distribuição dos espaços e como o prédio se integrará ao ambiente urbano ao redor. Você projeta a estrutura básica do prédio, considerando fatores como segurança, eficiência e funcionalidade.

Isso equivale à arquitetura de software, onde envolve decisões sobre a estrutura básica do sistema, como a escolha da linguagem de programação, o estilo arquitetural (por exemplo, MVC, cliente-servidor, microservices), a distribuição de responsabilidades entre os diferentes componentes (por exemplo, front-end, back-end, banco de dados), a escalabilidade e a segurança do sistema.

Por exemplo, ao desenvolver um sistema de e-commerce, o arquiteto de software pode decidir usar uma arquitetura cliente-servidor, onde o cliente (o navegador da web do usuário) faz solicitações para o servidor, que por sua vez processa essas solicitações e retorna as respostas adequadas. O arquiteto também decide como os dados serão armazenados, como os diferentes módulos do sistema se comunicarão e como o sistema será escalável para lidar com um grande número de usuários simultâneos.

Agora, imagine que você é um designer de interiores contratado para decorar os interiores desse prédio. Sua tarefa é decidir como cada ambiente será organizado, escolher os móveis e acessórios, selecionar as cores das paredes e os tipos de iluminação para criar uma atmosfera agradável e funcional em cada espaço. Você se preocupa com os detalhes de cada sala, garantindo que seja confortável, esteticamente agradável e atenda às necessidades dos ocupantes. Isso representa o design de software, onde envolve detalhes específicos sobre como os diferentes componentes do sistema serão implementados e interagem entre si para alcançar os objetivos definidos na arquitetura.

Continuando com o exemplo do sistema de e-commerce, o design de software envolveria decidir como a página de produtos será exibida, quais informações serão exibidas em cada página, como o processo de checkout será implementado, como as informações do usuário serão validadas e como os pedidos serão processados e armazenados no banco de dados.
Cada componente do sistema, como o carrinho de compras, a página de perfil do usuário e o sistema de pagamento, seria cuidadosamente projetado para garantir que seja eficiente, seguro e fácil de usar para os usuários.

Em resumo, enquanto a arquitetura de software define a estrutura geral e as diretrizes de comunicação do sistema, o design de software se concentra nos detalhes de implementação e na aparência das interfaces do usuário. Em conjunto, a arquitetura e o design de software desempenham papéis complementares na criação de sistema.

#4 Estudos: Explorando a Evolução das Arquiteturas de Software

Gabriel Alcara — Thu, 29 Feb 2024 22:01:36 +0000

Desde os primórdios do desenvolvimento de software, arquitetos e engenheiros têm buscado constantemente maneiras de projetar sistemas robustos e escaláveis. A jornada rumo à arquitetura de software ideal tem sido marcada por uma evolução contínua, onde cada estágio trouxe consigo novos desafios e oportunidades.

Neste contexto, é fundamental compreender a trajetória que nos levou às arquiteturas de software contemporâneas, como a Clean Architecture. Antes de mergulharmos nesse paradigma, é crucial explorar os diferentes tipos de arquitetura que moldaram o cenário do desenvolvimento de software ao longo do tempo.

Arquitetura Monolítica:

Uma das primeiras abordagens arquiteturais, a arquitetura monolítica, apresenta-se como um marco inicial na história do desenvolvimento de software. Neste modelo, um único aplicativo é concebido e implantado como uma entidade coesa, frequentemente representada por uma única base de código. Embora ofereça simplicidade na concepção e desenvolvimento, a arquitetura monolítica pode enfrentar desafios significativos em termos de escalabilidade e manutenção, especialmente à medida que o sistema cresce em complexidade e escopo.

Arquitetura em Camadas:

Em busca de uma maior organização e separação de responsabilidades, surgiu a arquitetura em camadas. Esta abordagem divide o sistema em diferentes estratos funcionais, como apresentação, lógica de negócios e acesso a dados. Cada camada desempenha um papel específico e interage com as camadas adjacentes de acordo com uma hierarquia estrita. Embora promova uma estrutura mais organizada, a arquitetura em camadas pode tornar-se propensa ao acoplamento excessivo e dificultar a modificação independente de cada camada.

Arquitetura Orientada a Serviços (SOA):

O advento da arquitetura orientada a serviços representou uma mudança paradigmática na concepção de sistemas de software. Neste modelo, as funcionalidades do sistema são decompostas em serviços independentes, interconectados por meio de interfaces bem definidas. Esta abordagem facilitou a integração de sistemas e promoveu a reutilização de componentes, mas também exigiu uma governança sólida e uma infraestrutura robusta de gerenciamento de serviços.

Arquitetura em Microservices:

Uma evolução natural da arquitetura orientada a serviços, a arquitetura em microservices propôs uma abordagem ainda mais granular e modular. Aqui, o sistema é dividido em serviços menores e autônomos, conhecidos como microservices, cada um responsável por uma função específica. Esta arquitetura oferece benefícios como escalabilidade granular, facilidade de implantação e manutenção, e capacidade de resposta rápida às demandas do mercado.

Arquitetura Hexagonal (Ports and Adapters):

Por fim, a arquitetura hexagonal, também conhecida como Ports and Adapters, introduziu um conceito revolucionário de isolamento do núcleo da aplicação. Propõe-se que o núcleo da aplicação, ou seja, as regras de negócios, seja protegido e desenvolvido independentemente de detalhes de implementação externa. Por meio de interfaces (ports) e adaptadores, esta arquitetura facilita a substituição de componentes externos e promove uma clara separação de preocupações.

A Clean Architecture, profundamente influenciada por esses paradigmas anteriores, surge como uma abordagem moderna e refinada para o desenvolvimento de software. Concentrando-se na separação clara de preocupações e na independência de detalhes de implementação, a Clean Architecture promove sistemas mais flexíveis, testáveis e de fácil manutenção, capacitando os desenvolvedores a enfrentar os desafios complexos do mundo digital contemporâneo.

#3 Estudos: Arquitetura Limpa

Gabriel Alcara — Tue, 27 Feb 2024 01:21:48 +0000

Sabemos que o objetivo principal da Clean Architecture é criar sistemas que sejam independentes de frameworks, testáveis e fáceis de entender, manter e evoluir ao longo do tempo.

A ideia central por trás da Clean Architecture é a separação de preocupações e a dependência de direção. O sistema é dividido em camadas concêntricas, onde cada camada tem uma responsabilidade específica e depende apenas das camadas internas. As camadas são organizadas de forma hierárquica, com as camadas mais internas contendo a lógica de negócios e as camadas mais externas tratando de detalhes de implementação, como interfaces com o usuário e bancos de dados..

Mas na prática como essa divisão ocorre na estrutura de diretórios do nosso sistema?

Suponha que estamos desenvolvendo um aplicativo de lista de tarefas com as seguintes funcionalidades:

Adicionar uma nova tarefa.
Exibir todas as tarefas.
Marcar uma tarefa como concluída.
Excluir uma tarefa.

Aqui está uma possível estrutura de arquitetura limpa:

Agora, vamos explicar a organização proposta:

domain: Este pacote contém a camada de domínio da aplicação. Ele inclui o modelo de domínio (Task) e os contratos de repositório (TaskRepository). Esta camada representa as regras de negócio do sistema e é independente de qualquer detalhe de implementação.

usecase: Aqui estão os casos de uso da aplicação, que representam as interações que o usuário pode ter com o sistema. Cada caso de uso é uma classe Java que contém a lógica necessária para realizar uma operação específica, como adicionar uma nova tarefa, recuperar todas as tarefas existentes ou marcar uma tarefa como concluída.

adapter: Este pacote contém os adaptadores para integrar o sistema com elementos externos. O subpacote delivery contém apresentadores que formatam os dados para serem entregues ao usuário. O subpacote gateway contém adaptadores que lidam com operações de banco de dados. O subpacote controller contém controladores que lidam com as solicitações HTTP.

TaskManagerApplication.java: Esta é a classe principal do Spring Boot, que inicia a aplicação e configura o contexto do Spring. Aqui é onde você pode definir as configurações do Spring Boot, como componentes, serviços, configurações de banco de dados, etc.

Essa estrutura segue os princípios da Clean Architecture, com a separação clara de responsabilidades e a direção das dependências, garantindo uma aplicação que seja independente de frameworks e fácil de entender, testar e manter.

#2 Estudos: Arquitetura Limpa

Gabriel Alcara — Thu, 22 Feb 2024 01:25:55 +0000

Quando mencionamos "arquitetura", muitos de nós imediatamente pensamos em prédios e construções físicas. No entanto, quando aplicamos o termo ao contexto de software, sua definição pode parecer menos intuitiva. Em vez de materiais como concreto e metal, o "material" da arquitetura de software é o próprio código - uma estrutura feita de instruções digitais intricadas.

A abstração do software pode tornar sua definição mais filosófica do que prática, pois tendemos a buscar paralelos em objetos físicos e concretos. No entanto, podemos entender a arquitetura de software como uma estrutura organizacional que divide o sistema em componentes, descreve suas interações e estabelece diretrizes para sua integração e organização.

Ao projetar um sistema de software, é essencial considerar diversos aspectos, como segurança, disponibilidade, flexibilidade para mudanças, manutenibilidade e recursos financeiros. A melhor abordagem arquitetural será aquela que se adapta às necessidades específicas do projeto, levando em conta esses requisitos.

É importante notar que, ao longo de décadas de experiência lidando com uma variedade de projetos de software, profissionais como Uncle Bob observaram padrões recorrentes na arquitetura de software. Como ele cita no livro, "As regras da arquitetura de software são independentes de todas as outras variáveis".

#1 Estudos: Arquitetura Limpa

Gabriel Alcara — Tue, 20 Feb 2024 21:15:11 +0000

Com base no livro Arquitetura limpa do famoso Uncle Bob e do video sobre esse tema do canal Código Fonte TV.

Link do livro na Amazon

Video Canal Código Fonte TV

Arquitetura Limpa:

Tem como objetivo a separação das preocupações do software.
Realiza a separação ao dividir o software em camadas.
Tem pelo menos uma camada para as regras de negócio e uma camada para a interface com o usuário.

Projetos de software desenvolvidos seguindo a arquitetura limpa costumam ter as seguintes características:

Independência de Frameworks: A arquitetura não depende da existência de nenhuma ferramenta externa a linguagem, como frameworks e bibliotecas, isso permite que você as use como tecnologias anexas ao projeto, ao invés de limitar o seu projeto as restrições de cada uma delas.
Testabilidade: Onde as regras de negocio do projeto podem ser testadas sem a necessidade de interface, banco de dados, servidor web ou qualquer outro elemento externo.
Independência da Interface do Usuário: A interface do usuário deve ser facilmente substituída, sem impactar o restante do sistema, por exemplo, uma interface web pode ser substituída por uma interface de console sem alterar as regras do negocio. Regras de negocio jamais devem ser implementadas na interface do usuário.
Independência de Banco de Dados: Assim como a interface do usuário, você deve ser capaz de trocar de banco de dados, por exemplo, de MySQL para Postgres com zero impacto nas regras pois elas não estão ligadas as diretamente as convenções e regras de um determinado banco de dados.
Independência de qualquer elemento externo: As regras de negocio não devem saber absolutamente nada sobre as interfaces com o mundo externo.

Fonte: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Camadas concêntricas:

Entities: Representam as tabelas do banco de dados dentro do projeto, aqui definimos as propriedades, tipos e acessos (getters e setters).
Use Cases: Representam as regras de negócio da aplicação, é responsável pela comunicação com as entidades, toda e qualquer informação deve passar por ela obrigatoriamente, em muitos casos a camada Service é usada como papel na camada de casos de uso.
Adapters ou Ports and Adapters: É feita a tradução para a comunicação com os elementos externos, nessa camada costumamos ter os controllers, presenters e repositories usados como adaptadores.
Frameworks and Drivers: É nessa camada que temos os elementos que precisam de alguma forma se comunicar com o núcleo do nosso projeto, banco de dados, frameworks, dispositivos e interfaces externas.

Podemos criar mais camadas se necessário, para separar ainda mais as responsabilidades, porém, sem interferir na regra da dependência.

Regra da Dependencia - As dependências devem sempre apontar para o nível mais alto da aplicação, ou seja, sempre para as camadas mais internas, as entities por exemplo, não podem saber nada do que ocorre na camada de use cases, que por sua vez, não deve saber nada da camada de adapters. O que queremos dizer é que qualquer alteração, por exemplo, na camada de controllers não deve impactar em absolutamente nada em que esteja na camada de casos de uso e nem na camada de entities.