Existem muitas metodologias, padrões e recursos no mundo do software, que auxiliam um desenvolvedor ou arquiteto, no processo de criação de um bom software, principalmente no que diz respeito à arquitetura e code design, mas será que você está fazendo isso corretamente?🤔
https://medium.com/@diego_moura/arquitetura-de-software-por-onde-come%C3%A7ar-e3b14da4533e
Comece pelo início…
Durante os anos em que tenho trabalhado com software, percebi um hábito nada incomum, praticado por diversos desenvolvedores e arquitetos que tive a oportunidade de trabalhar junto, que basicamente se resume em confundir dois conceitos centrais — Arquitetura e Code Design ou apenas Design. Muitos deles iniciavam um “projeto arquitetural” questionando elementos do code design, muitas vezes relacionados a um framework especificamente, e não da arquitetura em si, direcionando seus esforços iniciais para o alvo errado. Então antes de mais nada, é necessário entender e separar esses dois conceitos.
Oque é Arquitetura?
Hipoteticamente falando, imagine que você esteja analisando a planta de uma construção civil, que foi desenhada por um arquiteto, e entregue à você. Ao segurar o documento em mãos, você percebe que nele contém o desenho de uma varanda com uma entrada frontal, logo em seguida uma pequena sala, mais adiante você vê um banheiro, próximo à um quarto, que está ligado à um corredor que leva até a cozinha, etc. Claramente você iria deduzir que o desenho remete a uma casa. O mesmo aconteceria, se essa planta fosse de um prédio, logo após receber o documento, bastaria pequenas análises para você perceber que se trata de um prédio. Isto é arquitetura!
Pense na arquitetura de software, como a planta da sua aplicação, ela deve dizer como as partes do seu software deverão ficar organizadas, separadas e interligadas, de forma clara e estruturada. Ao analisar a planta da sua aplicação, você deverá ser capaz de dizer do que se trata aquela planta. Se estivermos falando de um sistema de ERP, você deve deduzir “ERP”, se estivermos falando de um Sistema de Cobranças, você deve deduzir “Sistema de Cobranças”, e não Spring, On Rails, Express, Web Api, etc.
A arquitetura é responsável por dividir o sistema em componentes menores, e definir como esses componentes irão se comunicar entre si. Ela deve dar suporte e orientar o desenvolvimento, manutenibilidade, implantação (deployment) e gerenciamento do software no nível mais alto. No entanto, diferentemente do code design, a arquitetura não tem um papel relevante no que diz respeito ao funcionamento do software como um todo. Existem diversos sistemas de software que funcionam perfeitamente bem, apesar de terem sido construídos em cima de uma péssima arquitetura. Mas obviamente, uma boa arquitetura, sempre dará suporte para um bom comportamento e escalabilidade do software. A arquitetura sempre irá preceder o code design.
Oque é Code Design?
Como o próprio nome já diz, o code design esta relacionado à aspectos de codificação. Da mesma forma como a arquitetura se preocupa em lidar com a organização dos componentes do software de nível mais alto, o code design se preocupa com a organização dos componentes do software, no nível do código.
Wht fck meaning that????
Não se preocupe… O que eu quis dizer é que, o code design é um conceito que pode ser associado ao conjunto de padrões e regras bem estabelecidas, que juntos irão organizar as estruturas de dados e funções no seu código, em classes ou abstrações de negócios, afim de deixar seu código mais resiliente, menos acoplado e apto à escalar. Ou seja, o code design se preocupa em como esses componentes de software no nível do código serão estruturados, organizados e como eles irão se comunicar entre si. Esta abordagem deve complementar os esforços de uma boa arquitetura, afim de manter o código limpo. Uma chamada para esse assunto são os princípios S.O.L.I.D e os design patterns (GoF).
“Bons sistemas de software começam com um código limpo. Por um lado, se os tijolos não são bem-feitos, a arquitetura da construção perde a importância. Por outro lado, você pode fazer uma bagunça considerável com tijolos bem-feitos. — Robert C. Martin (Uncle Bob)”
Não irei me aprofundar nesse assunto neste artigo. Em breve irei publicar um handbook bem bacana que estou escrevendo, e lá mostrarei diversos conceitos, mitos, padrões, anti-padrões, e melhores práticas no que diz respeito à code design, de forma bem democrática, sem apego à qualquer linguagem de programação ou framework.
Iniciando…
Bom, agora que temos compreendido as diferenças entre code design e arquitetura, por onde devemos começar a desenhar a nossa arquitetura?
A arquitetura relaciona alguns conceitos como políticas, níveis, regras de negócios, entidades e casos de uso. E será em cima desses conceitos que nós trabalharemos as visões de como iniciar uma boa arquitetura. Vamos lá!
Política
Um software, é composto por definições políticas. As políticas descrevem O QUE um software faz. As políticas de alto nível podem ser dividas em muitas outras declarações políticas menores e diferentes umas das outras. Algumas dessas políticas menores descreverão como algumas regras de negócio deverão ser executadas no sistema. Outras políticas descreverão aspectos que não necessariamente estejam ligados às regras de negócios, como por exemplo a formatação de um relatório, ou a validação de campos na entrada, etc.
Uma boa arquitetura depende de um bom entendimento das políticas do software em sua totalidade, para que depois de compreendidas, elas possam ser separadas ou agrupadas cuidadosamente, com base nas razões pelas quais elas mudam. As políticas que mudam pelas mesmas razões e no mesmo momento, pertencerão ao mesmo componente, e estarão no mesmo nível. Assim como as políticas que mudam por razões diferentes e em momentos diferentes, pertencerão à outros componentes, e estarão em níveis diferentes.
Nível
O nível basicamente descreve o quão longe determinada política está das entradas/saídas (I/O). Quanto mais distante da camada de IO, maior o nível da política. Logo compreende-se pelas políticas de nível mais baixo, aquelas que lidam diretamente com aspectos de entrada e saída da aplicação.
Regras de negócio
Compreenda as regras de negócio como procedimentos que geram valor diretamente para a empresa, neste caso, como regras que façam a empresa lucrar ou economizar dinheiro diretamente. As regras de negócio estão indissociavelmente ligadas aos dados de negócio, e esta relação entre as regras de negócio e os dados de negócio, compõem um objeto de negócio, que nós comumente chamamos de entidade de negócio. (Quanto negócio, ne? rsrs)
Entidades
As entidades de negócios são compostas por um pequeno conjunto de regras de negócio. Um bom exemplo de abstração de entidade, seria utilizando o paradigma de programação orientada a objetos, através de uma classe representada por UML. Por exemplo a entidade Aluno abaixo:
A definição de entidades não parte do pressuposto que a linguagem utilizada no projeto suporte o paradigma POO. Para caracterizar uma entidade, basta agrupar regras de negócios e os dados de negócios, com base nas políticas do seu software, e separa-los para que sejam puras, e não tenham nenhum tipo de acoplamento ou dependência com a camada de banco de dados, interfaces dos usuário ou frameworks.
Casos de uso
Agora que sabemos que um software é composto por políticas de alto, médio e baixo nível, e que as políticas descrevem como as regras de negócios devem ser executadas. Assim como sabemos que as regras de negócios agrupadas aos dados de negócio formam as entidades de negócios, então nos resta compreender o que são os casos de uso.
Um caso de uso é uma descrição de como um software deve ser utilizado em determinados momentos. O caso de uso especifica as entradas, a saída e como os dados serão manipulados no processamento do fluxo para obtenção da saída. Por exemplo:
Perceba que os casos de uso descrevem a forma de como e quando as regras de negócios serão invocadas dentro das entidades.
“Os casos de uso controlam a dança das entidades — Clean Architecture”
Conclusão
Como vimos, para iniciarmos uma boa arquitetura, devemos nos preocupar com aspectos relacionados à abstração de negócio, começando pelas políticas em seus respectivos níveis. Tendo definido as políticas, separe as que mudam por razões diferentes e agrupe as que mudam pelas mesmas razões. A partir das políticas menores, defina como deverão ser executadas as regras de negócios (aquelas regras que geram valor para empresa). Ao definir as regras de negócios, você se deparará com os dados de negócios, que são os dados manipulados para que determinada regra de negócio esteja presente no seu software. Feito isso, você poderá definir quais entidades de negócio existem na sua arquitetura. Definida as entidades, e compreenda como e quando os casos de uso irão invocar as regras de negócios existentes em cada entidade.
Bom… É isso ai! Espero ter contribuído de alguma forma!! 😁
#happyCoding