A arquitetura limpa (Clean Architecture) é uma abordagem que visa a separação de preocupações em sistemas de software, permitindo maior flexibilidade, testabilidade e manutenção. A arquitetura é composta por camadas, incluindo a camada de apresentação, camada de domínio e camada de dados. A regra de dependência exige que as dependências do código-fonte só possam apontar para dentro, o que significa que nada em um círculo interno pode saber nada sobre algo em um círculo externo.
Neste artigo, apresentamos uma proposta de estruturação do Clean Architecture visando a melhorar as interações entre Cientistas de Dados e Software Engineer. A proposta feita no presente texto está baseada na identificação dos principais pontos de interação entre esses profissionais.
Clean Architecture, divisão por camadas e equipes multidisciplinares
Equipes multidisciplinares e arquitetura de camadas são conceitos que se complementam bem. A criação de equipes multidisciplinares é essencial para o sucesso do desenvolvimento de software, pois permite que diferentes especialistas trabalhem juntos em um projeto. Por outro lado, a arquitetura de camadas é uma abordagem para dividir um sistema em diferentes camadas lógicas, cada uma com uma responsabilidade específica. A combinação desses dois conceitos pode ajudar a criar um software de alta qualidade.
Ao usar uma abordagem de camadas, é possível definir claramente as responsabilidades de cada equipe e garantir que haja uma separação clara de preocupações. Por exemplo, uma equipe de cientistas de dados pode trabalhar em camadas de dados e processamento, enquanto uma equipe de desenvolvedores de software pode trabalhar em camadas de apresentação e infraestrutura. Isso permite que cada equipe se concentre em sua área de especialização e trabalhe de forma mais eficaz.
Benefícios da arquitetura de camadas no desenvolvimento de software
Criar camadas para separar o trabalho do cientista de dados e desenvolvedor de software pode trazer vários benefícios importantes. Aqui estão alguns deles:
- Clareza de responsabilidades: ao definir as camadas de software, fica claro qual equipe é responsável por cada camada. Isso ajuda a evitar conflitos e mal-entendidos sobre quem é responsável pelo quê.
- Maior produtividade: ao separar as camadas, cada equipe pode se concentrar em sua área de especialização e trabalhar de forma mais produtiva. Isso pode levar a uma entrega mais rápida e eficiente do software.
- Maior qualidade do software: separar as camadas também permite que cada equipe se concentre em seu trabalho específico. Isso pode levar a um software de melhor qualidade, pois cada equipe pode dedicar mais tempo e recursos às suas tarefas.
- Melhor colaboração: ao separar o trabalho em camadas, as equipes podem colaborar de forma mais eficaz. Cada equipe pode se concentrar em sua área de especialização e trabalhar em estreita colaboração com a outra equipe. Isso pode levar a uma melhor comunicação e um melhor entendimento dos requisitos do projeto.
- Facilidade de manutenção: separar as camadas também torna mais fácil manter o software a longo prazo. Cada equipe pode se concentrar em manter sua camada específica e garantir que ela esteja funcionando corretamente. Isso pode levar a uma manutenção mais fácil e eficiente do software.
Clean Architecture (Arquitetura Limpa)
Nos últimos anos, vimos toda uma gama de ideias sobre a arquitetura de sistemas, as quais incluem:
- Hexagonal Architecture
- Onion Architecture
- Screaming Architecture
- DCI
- BCE
Embora todas essas arquiteturas variem um pouco em seus detalhes, elas são muito semelhantes. Todas elas têm o mesmo objetivo, que é a separação de preocupações. Todas elas conseguem essa separação dividindo o software em camadas. Cada um tem pelo menos uma camada para regras de negócios e outra para interfaces.
Baseado nessas informações e com o objetivo de integrar os pontos fundamentais dessas arquiteturas, Robert C. Martin (Uncle Bob) propõe a arquitetura representada na seguinte figura 1.
A Camada de Apresentação contém UI (Atividades e Fragmentos), que são coordenados por Apresentadores/ViewModels que executam um ou vários casos de uso. A Camada de Apresentação depende da Camada de Domínio.
A Camada de Domínio é a parte mais interna da “cebola” (sem dependências com outras camadas) e contém entidades, casos de uso e interfaces de repositório. Os casos de uso combinam dados de 1 ou várias interfaces de repositório.
A Camada de Dados contém implementações de repositório e 1 ou várias fontes de dados. Os repositórios são responsáveis por coordenar os dados das diferentes fontes de dados. A Camada de Dados depende da Camada de Domínio.
Os círculos concêntricos representam diferentes áreas de software. Em geral, quanto mais você avança, mais alto o software se torna.
A regra primordial que faz essa arquitetura funcionar é a regra de dependência. Essa regra diz que as dependências do código-fonte só podem apontar para dentro. Nada em um círculo interno pode saber absolutamente nada sobre algo em um círculo externo. Em particular, o nome de algo declarado em um círculo externo não deve ser mencionado pelo código no círculo interno. Isso inclui, funções, classes, variáveis ou qualquer outra entidade de software nomeada.
Da mesma forma, os formatos de dados usados em um círculo externo não devem ser usados por um círculo interno, especialmente se esses formatos forem gerados por uma estrutura em um círculo externo. Não queremos que nada em um círculo externo afete os círculos internos.
Clean Architecture é sobre acoplamento. Não há prescrição para as camadas que você define ou como você define o acoplamento. Você não precisa definir camadas por projetos. É sobre a direção das dependências entre os tipos. O acoplamento aferente e eferente é o que define a estabilidade de cada camada. Motivo pelo qual pessoas envolvidas em projetos onde a Clean Architecture é aplicada devem ter uma boa ideia dos princípios que se aplicam nessa arquitetura.
A importância da ciência de dados
A principal responsabilidade de cientistas de dados é trabalhar com dados para obter insights, realizar análises e criar modelos. No entanto, a qualidade do código é importante para garantir que os projetos sejam escaláveis, fáceis de manter e reutilizáveis, e que possam ser desenvolvidos com eficiência e eficácia.
Existem muitas habilidades necessárias para realizar o trabalho desses especialistas. Na Figura 2 apresenta-se um conjunto de habilidades e processos que devem ser seguidos para o trabalho com dados. Esses processos exigem um conjunto de conhecimentos muito profundos em estatísticas, matemática, tratamento de dados, visualização de dados para comunicar os resultados da análise de dados de maneira clara e eficaz, dentre outras habilidades.
Como a Ciência de Dados é um campo em constante evolução, é importante que os profissionais que desempenham esse trabalho estejam continuamente aprendendo e se atualizando em novas técnicas e tecnologias. Isso pode incluir a participação em cursos e treinamentos, a leitura de artigos e livros sobre Ciência de Dados e a participação em comunidades da área.
A qualidade e incerteza dos dados podem ter um impacto significativo no tempo que os cientistas de dados devem investir em cada fase do processo de análise de dados. A coleta e limpeza de dados podem ser particularmente demoradas, já que os dados podem estar em formatos diferentes e podem conter erros, valores ausentes ou dados duplicados. A análise de dados também pode ser afetada pela qualidade dos dados, pois dados de baixa qualidade podem levar a insights imprecisos ou equivocados.
Como resultado, cientistas de dados podem precisar revisitar essas fases do processo várias vezes para garantir que os dados estejam limpos e prontos para a análise. Isso pode ser especialmente desafiador em projetos de grande escala, onde há uma grande quantidade de dados para serem analisados.
No entanto, é importante lembrar que o investimento de tempo nas fases iniciais do processo de análise de dados pode economizar tempo e esforço no longo prazo, garantindo que os dados sejam limpos e precisos antes da análise. Além disso, a iteração contínua pode levar a melhorias significativas na análise de dados e na qualidade dos resultados.
Embora a programação seja uma habilidade importante para um cientista de dados, não é necessário que sejam especialistas em programação. Muitas vezes, cientistas de dados trabalham em colaboração com engenheiros de software ou desenvolvedores para garantir que o código seja escrito de maneira eficiente e eficaz. Isso pode envolver a revisão do código de outros desenvolvedores e garantir que ele siga as melhores práticas de programação e padrões de código.
Além disso, muitas organizações têm equipes dedicadas de engenharia de software que garantem a qualidade do código e a conformidade com as melhores práticas de programação. Nesses casos, os cientistas de dados podem se concentrar em suas principais responsabilidades de análise de dados e modelagem, enquanto os engenheiros de software se concentram na qualidade do código.
Uma boa arquitetura de software irá promover a interdependência entre cientistas de dados e engenheiros de software. Motivo pelo qual a seguir abordaremos uma proposta de uso do Clean Architecture desde a óptica de equipes multidisciplinares de cientistas de dados e engenheiros de software.
Clean Architecture na Ciência de Dados
Ao aplicar a Clean Architecture na Ciência de Dados, é importante identificar as diferentes camadas do sistema e suas responsabilidades, incluindo a camada de dados, a camada de infraestrutura, a camada de negócios e a camada de apresentação. Cada camada deve ser projetada para ser independente das outras camadas, permitindo que o sistema seja facilmente adaptável a mudanças nos requisitos de negócios ou tecnologias.
Contextos que envolvem processamento de dados tem como foco principal a lógica de negócios (business logic) encarregada dos processos de transformação ou cálculo dos dados, além do encaminhamento destes para pessoas ou software (workflow).
As regras de negócios são expressões formais da política de negócios. Qualquer coisa que seja um processo ou procedimento é uma lógica de negócios e qualquer coisa que não seja um processo nem um procedimento é uma regra de negócios. Daí que processos tais como ETL, análise e inferência de dados sejam pertinentes à lógica de negócios e fazem parte dos casos de uso na camada de domínio.
Uma possível subdivisão a realizar a fim de independizar o trabalho de cientistas de dados e engenheiros de software seria na camada de domínio, com um modelo segundo os seguintes tipos de Casos de Uso:
- Processamento dos dados provenientes das fontes de dados: a camada contempla a orquestração do fluxo de dados visando a persistência, consistência e validação dos dados.
- Desenvolvimento e manutenção de modelos: processo de usar o conhecimento do domínio para selecionar e transformar as variáveis mais relevantes dos dados brutos ao criar um modelo preditivo usando aprendizado de máquina ou modelagem estatística.
- Processos que envolvem diretamente o usuário final
Por outro lado, a camada de dados passará a estar conformada pelos Repository, e tarefas (tasks) que conformam o fluxo de dados.
Note-se que essa separação implica que ferramentas ETL ou ELT sejam conformadas por duas camadas. Uma delas relativa à lógica de negócios contemplando a modelação do workflow de dados e a outra com a lógica de acesso e compartilhamento de dados, sendo que na segunda camada existe espaço para aplicação de princípios de software.
No nível de armazenamento da camada de dados é possível fazer uma subdivisão dos dados segundo esquemas ou bancos de dados diferentes, refletindo a separação em camadas segundo Caso de Uso. No entanto, é importante ter em mente que a criação de esquemas ou bancos de dados separados pode aumentar a complexidade da aplicação e exigir mais recursos de gerenciamento de dados. Portanto, é importante manter bem definido e documentado o objetivo de cada uma das camadas que são criadas.
Conclusão – Clean Architecture aplicada na Ciência de Dados
Na ciência de dados, a arquitetura limpa pode ser aplicada para criar uma arquitetura de aplicação orientada a aplicações de ciência de dados. A camada de domínio pode ser subdividida em casos de uso, incluindo processamento de dados, desenvolvimento e manutenção de modelos e processos que envolvem diretamente o usuário final.
A camada de dados pode ser conformada por Repository e tarefas (tasks) que conformam o fluxo de dados. É possível fazer uma subdivisão dos dados de acordo com esquemas ou bancos de dados diferentes, refletindo a separação em camadas de caso de uso.
Quem é a Aquarela Analytics?
A Aquarela Analytics é vencedora do Prêmio CNI de Inovação e referência nacional na aplicação de Inteligência Artificial Corporativa na indústria e em grandes empresas. Por meio da plataforma Vorteris, da metodologia DCM e o Canvas Analítico (Download e-book gratuito), atende clientes importantes, como: Embraer (aeroespacial), Scania, Mercedes-Benz, Grupo Randon (automotivo), SolarBR Coca-Cola (varejo alimentício), Hospital das Clínicas (saúde), NTS-Brasil (óleo e gás), Auren, SPIC Brasil (energia), Telefônica Vivo (telecomunicações), dentre outros.
Acompanhe os novos conteúdos da Aquarela Analytics no Linkedin e assinando a nossa Newsletter mensal!
Autor
Desenvolvedor Python na Aquarela Advanced Analytics. Mestrado em Informatica pela PUC-Rio (CAPES 7). Graduação em Ciência da Computação pela Universidade da Havana. Na minha carreira tenho participado de vários projetos envolvendo desenvolvimento de software, processamento de dados e Ciência de dados.