Quem é desenvolvedor já deve ter trabalhado em sistemas desorganizados; em sistemas novos que começaram organizados e que acabou se tornando desorganizado ao longo do tempo.

Você já ficou na dúvida de onde colocar alguma classe, função e colocou num pacote chamado "utils".

Tudo isso afeta a qualidade final da arquitetura e do código como um todo.

Quanto mais complexo um sistema, mais esforço deve ser feito para manter uma organização. Um sistema nesse sentido é parecido com uma casa, é necessário dar manutenção senão ela desaba.

Nosso cérebro naturalmente organiza as coisas em blocos, na arquitetura essa organização do código se dá por módulos, e aqui cabe uma definição de módulo que abriga o mesmo conceito independente da linguagem utilizada.

Modularidade é o agrupamento lógico de códigos relacionados.

Para discussões de arquitetura, usamos modularidade como um termo geral para grupos de códigos relacionados: classes, funções, ou qualquer outro tipo de agrupamento.

Modularidade não requer uma separação física. Por exemplo, é possível ter um monolito com suas classes no mesmo projeto, mas com uma separação lógica. Se chegar o momento que seja necessário separar o código em alguns microservicos, o esforço seria menor. O porém é que separação lógica e não física requer mais maturidade da equipe de não misturar os conceitos, quando tem essa barreira física, é mais dificil misturar.

Faz parte do papel do Arquiteto e do desenvolvedor de gastar "energia" para garantir a manutenção saudável do sistema. E essa organização do código, é uma característica implicita de arquitetura, nenhum cliente passa o requisito específico de manter o código organizado (manutenabilidade).

Um arquiteto deve estar ciente de como os desenvolvedores organizam as coisas, porque isso tem implicações importantes na arquitetura. Se os pacotes estão muito acoplados, reutilizá-los para trabalhos relacionados fica mais difícil.

Eu considero também que muitas vezes a organização dos pacotes pelos desenvolvedores, demonstra uma falta de conhecimento da equipe de como a arquitetura funciona e também temos os problemas com a modelagem de dados.

Medindo Modularidade

Temos três conceitos fundamentais para medir modularidade de um sistema, coesão, acoplamento e connascence (sem tradução para o português). E temos métricas para medí-los.

Aqui cabe um aviso, eu coloquei os exemplos nos conceitos que foram mais complicados para entender.

Coesão

Coesão mede o quanto as partes são relacionadas entre si. O quanto os indivíduos daquele grupo fazem realmente parte daquele grupo.

Idealmente você deve agrupar partes que são inerentemente dependentes, tanto que se você quebrar em módulos menores, você ainda vai ter que relacionar eles por chamadas.

Cientistas da computação definiram um grupo de medidas de coesão, listado do melhor para o pior.

1. Coesão funcional

   Cada parte do módulo está relacionada entre si e o módulo contém tudo que é essencial para funcionar. Esse é o mundo perfeito da coesão.

2. Coesão sequencial

   Dois módulos interagem, onde a saida de um se torna a entrada do outro.

   Pegando um exemplo simples, programação funcional tem muita coesão sequencial. No exemplo abaixo, o select só vai pegar os dados das pessoas filtradas pelo Where.

      var pessoas = new List<Pessoa>() {new(10, "Jose"), new(18, "Maria")};
   
      return pessoas.Where(p => p.Idade >= 18).Select(p => p.Nome);
   

3. Coesão comunicacional

   Demorei um pouco para formular na minha cabeça sobre esse tipo de coesão, a chave para entender são os dados. Os dados são compartilhados entre os elementos do módulo ou entre os módulos, gerando uma relação entre eles. A fonte de informação é a mesma, porém as tarefas a serem executadas podem ser diferentes.

   No livro eles fazem um exemplo com salvar dados no banco e enviar um email. Abaixo um exemplo em C# onde o ponto de coesão são os valores (data) utilizados nos dois métodos distintos.

    using System;
    using System.Linq;
   
    class Program
    {
        static void Main()
        {
            // Exemplo de dados
            int[] data = { 10, 5, 8, 15, 7 };
   
            // Chamando funções do módulo estatístico
            double average = CalculateAverage(data);
            int sum = CalculateSum(data);
   
            // Exibindo resultados
            Console.WriteLine($"Média: {average}");
            Console.WriteLine($"Soma: {sum}");
        }
   
        // Função para calcular a média
        static double CalculateAverage(int[] values)
        {
            // A coesão comunicacional acontece através do parâmetro 'values'
            double average = values.Average();
            return average;
        }
   
        // Função para calcular a soma
        static int CalculateSum(int[] values)
        {
            // A coesão comunicacional acontece através do parâmetro 'values'
            int sum = values.Sum();
            return sum;
        }
    }
   

4. Coesão procedural

   Dois módulos devem executar o código numa ordem particular. Como no exemplo abaixo a função "CalculateStatistics" funciona de maneira procedural, onde cada passo é necessario ser realizado em ordem para ter o resultado.

    using System;
    using System.Linq;
   
    class Program
    {
        static void Main()
        {
            // Exemplo de lista de números
            int[] numbers = { 5, 8, 2, 10, 7 };
   
            // Chamando funções do módulo de manipulação de lista
            CalculateStatistics(numbers);
        }
   
        // Função procedural para calcular média e desvio padrão
        static void CalculateStatistics(int[] values)
        {
            // Calcula a média
            double average = values.Average();
            Console.WriteLine($"A média dos números é: {average:F2}");
   
            // Calcula o desvio padrão
            double sumOfSquares = values.Sum(v => 
                Math.Pow(v - average, 2));
            double variance = sumOfSquares / values.Length;
            double standardDeviation = Math.Sqrt(variance);
            Console.WriteLine($"O desvio padrão dos números é: 
                {standardDeviation:F2}");
        }
    }
   

5. Coesão temporal

   Módulos estão relacionados com base no tempo. Eles não tem relação entre eles a não ser pela característica temporal. Por exemplo, o Startup de uma aplicação .NET.

    var builder = WebApplication.CreateBuilder(args);
   
    // Add services to the container.
    builder.Services.AddControllers();
   
    builder.Services.AddEndpointsApiExplorer();
    builder.Services.AddSwaggerGen();
   
    var configuration = builder.Configuration;
   
    var connectionString = configuration.GetSection(
    "ConnectionStrings:DefaultConnection");
   
    builder.Services.AddHealthChecks(configuration);
   

6. Coesão lógica

   Os dados dentro do módulo são relacionados lógicamente, mas não funcionalmente. O pacote StringUtils do Java, são métodos que atuam em cima da String, mas fora isso não tem relação um com outro.

7. Coesão coincidente.

   Elementos do módulo não são relacionados a não ser estar na mesma pasta. (Pior cenário, o utils)

Como medir coesão?

LCOM, que significa "Lack of Cohesion of Methods," é uma métrica usada para avaliar a coesão em uma classe em programação orientada a objetos. Coesão refere-se à medida em que os membros de uma classe (métodos e campos) estão relacionados uns com os outros. Uma coesão alta indica que os membros estão fortemente relacionados e trabalham juntos para alcançar um propósito comum. Por outro lado, uma coesão baixa sugere que os membros da classe podem não estar tão relacionados e podem ter responsabilidades divergentes.

A métrica LCOM é uma maneira de quantificar a coesão em uma classe, com o objetivo de avaliar a qualidade do design do software.

A ideia é contar quantos pares de métodos não compartilham campos em comum e, em seguida, calcular a porcentagem disso em relação ao número total de pares de métodos possíveis.

É importante notar que a métrica LCOM é uma ferramenta e não deve ser usada isoladamente para avaliar a qualidade de um design. Ela fornece insights sobre a coesão, mas o contexto e a compreensão mais profunda do código são essenciais para uma avaliação completa. Além disso, existem outras métricas de coesão e acoplamento que podem ser usadas em conjunto para fornecer uma visão mais abrangente da qualidade do design do software.

Acoplamento

Acoplamento refere-se ao grau de interdependência entre módulos de um sistema.

Assim como coesão ele é dividido em diferentes categorias da melhor para pior.

1. Dados

   Acoplamento de dados ocorre quando os módulos compartilham dados através de parametros, mas não tem conhecimento da implementação interna um do outro. Além de que um dado nao altera o dado do outro módulo.

2. Estrutura de Dados

   Em inglês é Stamp, algo como carimbo, mas eu achei melhor colocar Estrutura de dados porque ele está relacionado com os módulos compartilharem estruturas completas de dados não apenas dados.

3. Controle

   Um módulo exerce controle no comportamento de outro módulo. Isso indica que um módulo possui conhecimento interno do outro módulo.

4. Externo

   O quanto um sistema depende de entidades externas aos módulos que estão sendo desenvolvidos. Dependencia de banco, de arquivos.

5. Comum

   Os módulos compartilham de um dado global. Então alterações nesses dados podem afetar todos os módulos.

6. Conteúdo

   Quando dois ou mais módulos compartilham código. Um afeta diretamente a funcionalidade do outro. Esse aqui me confundiu um pouco. Eu entendo como uma falha de implementação em modificadores de acesso no caso do C#.

Como medir acoplamento?

Edward Yourdon e Larry Constantine definiram duas métricas de acoplamento. A Aferente e a eferente.

Aferente mede o número de conexões chegando (incoming) para um artefato de código.

Eferente mede o número de conexões saindo (outgoing) para outros artefatos de código.

No geral os tipos de conexões podem variar se são piores ou melhores. Para o quesito acoplamento, conexões aferentes (que estão chegando) são piores que as eferentes, porque significa que alterações em outros módulos podem quebrar o seu módulo e isso tem haver com métricas criadas pelo Robert Martin que explico a seguir.

Abstração, instabilidade e distância da sequencia principal.

Essas métricas foram criadas pelo Robert Martin para uma linguagem específica (C++), mas pode ser utilizado em outras linguagens.

Abstração

Abstração é a razão de artefatos abstratos (classes abstratas, interfaces) para artefatos concretos (implementação).

Existe um extremo que é sem nenhuma abstração, o código está todo no "main" e no outro extremo muita abstração pode se tornar mais complicado para o desenvolvedor de entender como as coisas se conectam.

A abstração é calculada pela razão da soma dos artefatos abstratos (interfaces e classes abstratas) com a soma das classes concretas.

$$A = \sum m^a \div \sum m^c$$

Instabilidade

É a razão entre acoplamento eferente com a soma de eferente + aferente.

A métrica de instabilidade determina a volatilidade do código fonte. Um código fonte que possui alta porcentagem de instabilidade quebra mais facilmente quando modificado devido a alto acoplamento.

É só pensar essa razão leva em conta o quanto o seu sistema depende de chamadas externas. Então quanto maior for e quanto mais facilmente seu sistema é quebrado por mudanças de fora.

A instabilidade é calculada pela soma dos acoplamentos eferentes (conexões que saem) dividido pela soma dos acoplamentos eferentes e aferentes.

$$I = C^e \div C^e + C^a$$

Distância da Sequencia principal

Essa distância é calculada pelo módulo da soma de "abstração" e "instabilidade" menos 1.

$$D = |A + I - 1 |$$

Essa sequencia principal define a relação ideal entre abstração e instabilidade. Sair dessa linha indica algum problema no seu módulo.

Connascence

Dois componentes são connascents se uma mudança em um exige uma mudança no outro para manter o sistema correto. - Meilir Page-Jones.

Existem dois tipos de connascence: Estática e Dinâmica.

Como os autores explicam, é um refinamento do acoplamento aferente e eferente. O arquiteto consegue ver pelos tipos de connascence o grau de acoplamento seja aferente ou eferente.

1. Connascence de Nome

   Componentes devem concordar com o nome de uma entidade. É o nível mais fraco de connasnce, porque mudar é facil, não gera tanto impacto.

2. Connascence de Tipo

   Componentes devem concordar com o tipo de uma entidade.

3. Connascence de Significado (Convenção)

   Componentes devem concordar com o significado de certos valores particulares. Exemplo clássico é o Boolean que é tratado em muitas linguagens como TRUE = 1 e FALSE = 0.

4. Connascence de Posição

   Componentes devem concordar com a ordem dos valores. Esse aqui é um exemplo muito comum quando o método tem como parâmetros por exemplo duas strings.

    void CreateCategory(String name, String description);
   

   Se o desenvolvedor trocar a ordem dos valores não vai gerar erro, mas semanticamente está errado.

5. Connascence de Algortimo

   Componentes devem concordar com um algoritmo. Um exemplo é o algoritmo de hash que deve rodar no cliente e no servidor devem ser o mesmo para autenticar um usuário, se um dos lados alterar o algoritmo, quebra o outro componente.

6. Connascence de Execução

   A ordem de execução dos componentes é importante.

7. Connascence de Timing

   O "timing" de execução de multiplos componentes é importante.

8. Connascence de Valor

   Ocorre quando vários valores relacionam entre si e devem mudar juntos. Pensando em uma estrutura de microserviço você tem seus diferentes contextos e compartilha algumas informações, quando um valor é alterado em um microserviço tem que ser atualizado no resto.

9. Connascence de Identidade

   Ocorre quando múltiplos componentes devem referencia a mesma entidade.

   Componentes independentes compartilham uma estrutura de dados em comum.

Quatro principais aspectos:

1. Compreender a diferença entre arquitetura e design e saber como auxiliar a equipe de desenvolvimento a implementar com sucesso a arquitetura.

2. Ter um amplo conhecimento em várias áreas e manter um profundo domínio em um nível específico, permitindo uma visão abrangente que o arquiteto percebe, mas os outros não.

3. Lidar com os "dependes" (ou "trade-offs", termo mais sofisticado em inglês). Nenhuma solução é perfeita; sempre haverá sacrifícios a serem feitos. A questão está em saber o que sacrificar e compreender as consequências disso.

4. E, o mais importante, uma visão arquitetural requer um entendimento de negócios. As decisões arquiteturais são baseadas nas necessidades do cliente e no contexto de negócios.

Arquitetura vs Design

Na abordagem tradicional, o arquiteto analisa todos os requisitos de negócio, define as características arquiteturais, seleciona os padrões arquiteturais e estilos que se adequam ao domínio do problema e cria os componentes. O resultado é então repassado à equipe de desenvolvimento, que é encarregada de criar os diagramas de classe para cada componente, desenvolver a interface do usuário, escrever o código-fonte e realizar testes.

É importante notar que, na abordagem tradicional, a comunicação é unidirecional, e o papel do arquiteto muitas vezes termina aí. No entanto, essa abordagem tradicional nem sempre funciona bem. O arquiteto deve fazer parte da equipe de desenvolvimento, e aqui estão algumas razões para isso:

Para ilustrar esse ponto, gostaria de compartilhar uma experiência recente que tive. Tive a oportunidade de projetar a arquitetura de um sistema para um cliente, mas, devido a várias razões, não pude acompanhar o desenvolvimento de perto. Algum tempo depois, fui convocado para uma reunião para discutir um possível problema no sistema. Esse problema não existia na arquitetura que propus e, no pior cenário, era mitigado. No entanto, durante o desenvolvimento, certas estruturas foram modificadas, e eu não fui informado sobre essas mudanças.

Outra situação que já vivenciei foi quando atuei como desenvolvedor. O arquiteto havia criado a estrutura inicial, mas não participou ativamente do desenvolvimento com a equipe. Como resultado, ele não percebeu os problemas e as dificuldades que a arquitetura apresentava para a equipe de desenvolvimento.

Mark Richards explica nesse vídeo de forma mais detalhada a diferença entre arquitetura e design, utilizando diversos exemplos. Recomendo assisti-lo para aprofundar sua compreensão sobre esse conceito.

Technical Breadth

A maioria de vocês já deve ter ouvido falar sobre o conceito de "desenvolvimento em T". Nesse modelo, você adquire conhecimento em diversas áreas, mas se especializa profundamente em um campo específico.

Por exemplo, um desenvolvedor de destaque terá um amplo conhecimento em um domínio específico, tornando-se um especialista nessa área. Portanto, seu perfil "T" se assemelha à imagem abaixo, com um grande conhecimento vertical em uma área específica, mas menos conhecimento horizontal em outras áreas.

No caso de um arquiteto de software, o conceito de "T" se assemelha mais à imagem abaixo. Enquanto ele pode ter especialização em áreas específicas, como uma forte compreensão da stack .NET ou da stack Java, ele também deve expandir seu conhecimento horizontal para avaliar e propor as melhores ferramentas, frameworks e linguagens para os projetos.

A pirâmide de conhecimento é uma representação conceitual que descreve a profundidade e a extensão do conhecimento de uma pessoa em relação a um determinado tópico ou campo de estudo. É comumente dividida em três partes:

1. O que você sabe: O topo da pirâmide é o conhecimento que você tem e reconhece ter. São informações, habilidades e conceitos que você possui e pode aplicar.

2. O que você sabe que não sabe: Essa camada representa o conhecimento que você reconhece não possuir, mas está ciente de sua existência. Inclui tópicos, habilidades ou informações que você sabe que precisa aprender ou explorar.

3. O que você não sabe que não sabe: está na base da pirâmide e representa o conhecimento que está além da sua consciência, coisas das quais você não tem conhecimento, e você não está ciente de sua existência.

Há muito tempo, eu estava envolvido no desenvolvimento de um sistema, porém, naquela época, meu conhecimento se limitava ao Asp.net WebForms. Eventualmente, deparei-me com a necessidade de uma solução mais adequada para um sistema específico, que, como descobri posteriormente, era uma Single Page Application (SPA). No entanto, naquele momento, eu nem sabia que existia algo chamado SPA. Para lidar com os desafios que o Asp.net WebForms não conseguia resolver, iniciei uma pesquisa e deparei-me com informações sobre frameworks como Ember e Angular, o que, por fim, me apresentou o conceito de SPA.

Como desenvolvedor, estamos constantemente em busca de aprimorar nossa base de conhecimento, visando ampliar o topo da "pirâmide de conhecimento". No entanto, é crucial reconhecer que o conhecimento que possuímos está sujeito ao avanço do tempo. Por exemplo, trabalhei com Angular há algum tempo, o que significa que ainda tenho algum entendimento sobre ele, embora meu conhecimento possa estar desatualizado devido às evoluções na área.

Um ponto fundamental destacado no livro é que a mudança de mentalidade de desenvolvedor para arquiteto implica, em grande parte, em equilibrar a expansão do topo da pirâmide com um foco na ampliação do "meio". Como arquiteto, é mais vantajoso possuir um conhecimento abrangente, mesmo que superficial, de diversos tipos de bancos de dados, em vez de se aprofundar em apenas um. Essa abordagem oferece uma visão mais holística e possibilita escolhas mais informadas ao projetar sistemas complexos.

Considero esse cenário bastante interessante. Compreendo o ponto de vista e, assim como os autores, acredito que essa seja a parte mais desafiadora durante a transição de carreira. É preciso fazer escolhas criteriosas sobre onde manter uma especialização e onde abrir mão, concentrando-se em expandir a base de conhecimento, já que nosso tempo é um recurso limitado.

Tive a sorte de ter trabalhado em ambientes nos quais fui exposto a uma ampla variedade de desafios. Embora meu foco de estudo seja predominantemente C# e o desenvolvimento no backend, tive a oportunidade de atuar em diversos contextos, envolvendo diferentes linguagens, bancos de dados, frameworks e áreas como frontend e desenvolvimento mobile. Essa diversidade de experiências tem enriquecido minha visão e habilidades, preparando-me para desafios mais amplos e complexos em minha carreira.

Trade-offs

A análise de trade-offs não é uma prática exclusiva de arquitetos. Desenvolvedores também devem considerar os prós e contras ao escolher uma estrutura de dados. Por exemplo, ao trabalhar em algoritmos complexos de otimização, uma decisão errada no código pode facilmente resultar em um StackOverflow.

No entanto, no caso dos arquitetos, o impacto de suas decisões é amplificado. As decisões arquiteturais afetam todo o ciclo de desenvolvimento de um projeto. Portanto, os arquitetos precisam ser cautelosos ao seguir tendências, pois nem todos os sistemas devem adotar uma arquitetura de microserviços, nem todos os bancos de dados precisam ser NoSQL. Múltiplos fatores devem ser levados em consideração.

Uma das restrições que, em minha opinião, mais influencia as decisões arquiteturais é a maturidade da equipe. Implantar uma arquitetura complexa em uma equipe com pouca experiência pode criar gargalos significativos no ciclo de desenvolvimento. Portanto, é importante considerar o nível de conhecimento e experiência da equipe ao tomar decisões arquiteturais.

Entender do Negócio

Ao criar uma arquitetura, uma das responsabilidades centrais de um arquiteto é a análise das necessidades do cliente. Isso envolve fazer as perguntas apropriadas para extrair os requisitos fundamentais do sistema e, em seguida, desenvolver a arquitetura com base nesses requisitos.

Frequentemente, o cliente expressa desejos que podem não se alinhar diretamente com as necessidades essenciais do projeto. Nesse cenário, cabe ao arquiteto gerenciar essas expectativas. Acredito que as habilidades interpessoais desempenham um papel crucial nesse processo, permitindo uma comunicação eficaz com o cliente e a capacidade de traduzir desejos em requisitos práticos.

Arquitetura e Codificação

Por fim, é importante destacar um aspecto do pensamento arquitetural, que é uma crença compartilhada pelos autores e que considero fundamental: o arquiteto deve ter experiência em desenvolvimento.

As estratégias para alcançar isso podem variar, e uma delas envolve a atuação do arquiteto como parte da equipe de desenvolvimento, embora em áreas que não causem gargalos para o progresso da equipe. Ou seja, funcionalidades críticas que impedem o avanço da equipe não devem ser de responsabilidade do arquiteto, já que ele tem outras funções a cumprir.

Outra estratégia proposta são as famosas POCs (Proof of Concept). A implementação dessas POCs serve para testar frameworks, tecnologias e bancos de dados. Além disso, essas POCs funcionam como um ponto de partida para que a equipe de desenvolvimento continue a implementação da funcionalidade.

Só uma coisa a se tomar cuidado nessas POCs. Geralmente quando fazemos POCs, pulamos algumas boas práticas para testar exatamente se aquilo é possível ser feito. É bom a gente tomar cuidado com isso, porque os desenvolvedores veem os arquitetos também como liderança técnica, então eles podem seguir o padrão da POC sem se preocupar com as boas práticas, fora que quantas vezes você não já viu uma POC entrar no código de produção? Aqui tem outra coisa que eu vou sugerir, esses códigos podem ser colocados como seu portifolio, mais um motivo para fazer um código bem feito.

Um outro ponto legal proposto é o arquiteto atuar em débito técnicos ou bugs. Eu acho essa abordagem muito interessante também porque é uma outra forma de avaliar os gaps ténicos da equipe e os gaps da própria arquitetura. Saber em que nível sua equipe de desenvolvimento está e como você pode ajudar eles a melhorar é um papel importante para o arquiteto. E você atuando nesses pontos, não afeta a equipe porque se não puder atuar não afeta o desenvolvimento, a revisão do código também ajuda a identificar esses gaps, não tem desenvolvimento, mas é sempre bom gastar um tempo analisando o código dos outros.

Por fim eu diria que a construção de bibliotecas, de uma sdk própria e ferramentas de automação ajudam a equipe a ganhar velocidade e ajuda a manter o conhecimento em desenvolvimento afiado.

Agradeço por ter chegado até este ponto!

Fique à espera dos próximos capítulos, nos quais, além dos resumos, compartilharei minhas experiências com as provas de conceito que venha a desenvolver e outros aprendizados relacionados ao desenvolvimento.