No dia 1° de Abril de 2011 eu fundei um grupo de arquitetura que amanhã, no último dia 1° completou 10 anos. É sobre essa história que vou falar hoje.

O ano era 2010, e eu já estava cansado dos mesmos assuntos, do bairrismo. Entrar na comunidade naquela época foi um desafio.

Os assuntos estavam rondando a mesma temática e falar de alguns projetos Open Source, ou mesmo compartilhar minha visão de mundo era muito difícil. Eu, como estava chegando, via críticas a tudo que eu defendia e acreditava, sinceramente parecia pessoal.

O bairrismo era esquisito, não era possível se opor sem tomar algumas boas pedradas. Os emails daquele grupo soavam como “Cala a sua boca, quem é você para dizer isso?” “Quem é você para dar opinião aqui?” sem, óbvio, dizer nada disso. Hoje relendo algumas threads eu até consigo enxergar a defesa técnica.

A verdade é que o próprio julgamento somado às críticas gera confusão, gera dor e angústia. 10 anos depois, o que aconteceu?

A criação do grupo

O grupo nasceu da ideia de falar sobre o que não era dito. Antes da era Satya não havia tanto espaço para falar de Open Source aqui no Brasil. Eu precisava de um espaço, onde o bairrismo, e aquela visão:

– Open Source é uma bosta estão ferindo minha tecnologia, falando de Open Source.

pudesse ser combatido e desencorajado.

Se o bairrismo aqui não fosse combatido pela própria Microsoft, com a entrada do Satya, eu acredito que .NET deixaria de ser mainstream antes de 2025. Não estava em apuros, mas precisaria rebolar demais para sustentar o ecossistema isolado do mundo.

Se fôssemos levar o bairrismo à frente como comunidade, não usaríamos diversas soluções como :

• Redis
• Elastic
• MongoDB
• Neo4J
• NGINX
• Docker
• Kubernetes
• Postgres, Oracle, MySQL
• Keycloak
• Jenkins
• SonarQube
• Kong
• Consul
• Vault
• Istio
• etcd

A gente pode passar o dia falando de produtos e projetos desenvolvidos em go, java, C++, Lua. E com o bairrismo, não poderíamos usá-las. Porque? porque não foram feitas nem em c# muito com alguma linguagem .NET Compliant.

Claro que muitas delas não existiam há 10 anos atrás, mas o fato é que não havia espaço seguro onde esse tipo de conteúdo fosse bem visto e bem vindo.

Aliás, eu estava começando a me distanciar da arquitetura de software, e estava em plena transição para a arquitetura de solução. Assuntos como DDD faziam muito menos sentido para mim do que Onion, Hexagonal e Clean Architecture.

Como surgiu o processo de candidatura?

Primeiro é preciso entender o que é um grupo de nicho. Os grupos de nicho são extremamente focados em um nicho específico. E sempre que os temas fogem ao nicho, isso produz uma sensação de não pertencimento podendo ocasionar evasão. Da exata mesma forma que produz uma sensação boa de pertencimento quando o conteúdo está aderente ao nicho.

É um jogo de preencher expectativas.

Então estava claro para mim, que perguntas de “como fazer um botão chamar um método no server”, ou como se faz um mapeamento em um ORM não era perguntas interessantes para o público que eu queria no grupo.

O conteúdo interessante deveria ser/ter:

• Disruptivo
• Gerar conflito de ideias
• Demandar reflexão
• Trazer algum conceito novo ou fundamentar o porque de algum conceito
• Autoral

Se gabaritasse essa lista, pra mim seria perfeito. Mas para mim bastava um desses pontos.

Mas ao criar um grupo chamado “Arquitetura de Software | .NET”, atraímos arquitetos, aspirantes a arquitetos e desenvolvedores que tinham como atividade trabalhar arquiteturas. Além de outros perfis.

E quando você é muito jr, e quer as respostas dos

Qual o caminho óbvio para quem quer ter uma dúvida respondida? Buscar o lugar com os melhores profissionais. É óbvio.

Mas como assegurar que esses melhores profissionais não percam o interesse no grupo com as perguntas do dia-a-dia de desenvolvimento?

Eu sabia que existia esse problema, mas não sabia como lidar com ele. E passei anos sem uma resposta para essa pergunta. Mas especificamente em um período em que rolava uma safra de questões do dia-a-dia, eu me dediquei bastante para entender como realizar algum tipo de filtro de entrada e que fosse imparcial.

Depois de refletir muito, eu cheguei à conclusão que não há nenhum tipo de filtro que pudesse ser à prova de injustiças. Deixar gente de fora é injusto por definição.

Mas como tornar esse processo, o mais justo possível?

Bom, antes de falar como tornar justo, eu vou contar sobre a escolha desse nicho. Eu queria sair da mesmice, achar um lugar para falar de temas que eram taboos aqui na comunidade. E quanto mais tempo perdermos com coisas do dia-a-dia, a energia é dissipada. É importante já termos superado assuntos básicos e também não concorrer com assuntos de outros grupos.

Nós estamos em diversos grupos, em cada um para falar de um assunto em específico.

E foi esse o pensamento que me fez chegar à conclusão que sim, mesmo sendo injusto, continuava sendo necessário fazer um filtro na entrada.

A forma mais transparente que encontrei foi o uso do linkedin.

Porque Linkedin?

Primeiro que LinkedIn é uma rede social, seu perfil é um currículo. Mentir no LinkedIn custa muito caro para a sua imagem, pois os seus pares olham para aquilo. E claro, há quem burle o LinkedIn para entrar no grupo, sim, mas em 2 minutos olhando o perfil descobrimos isso. Eu faço isso há anos. Os que passarem do filtro, se comportarão no grupo, já que aquilo custou esforço de forjar um LinkedIn fake.

As competências do Linkedin são atribuídas por outras pessoas, como recomendações em determinados assuntos ou skills. Então para entrar no grupo eu uso essas competências como critério. Então uma quantidade X de pessoas precisa atestar que você é competente em C#, por exemplo, se estamos falando de um grupo .NET.

Aliás eu não estou preocupado com uma pergunta ou outra, estou preocupado com o grupo como um todo. Então se vazar uma pergunta boba ou outra é relevado, mas se isso se torna um padrão eu tomo ações mais drásticas.

Os posts, tutoriais e hello world?

Esse é um ponto em que, infelizmente eu perdi o controle. Sobre esse assunto eu só tenho a me desculpar. Não há o que dizer.

Qual é o futuro do grupo?

Sinceramente eu ainda estou pensando sobre isso. O Andre Secco, o Balta e o Fabrico Veronez já criaram ou estão criando suas comunidades no Discord. Sinceramente eu tenho pensado muito sobre isso.

Embora eu curta demais o telegram estou tendo dificuldade com muitos grupos no telegram.

A gente forjou o dotnetbr que hoje está com 2970 membros, no ano passado recebi o ownership do grupo. Ainda temos o arquiteturadotnet com 1008 membros lá também, já o RabbitMQ BR são 377 membros. E nos grupos privados do Docker Definitivo, que já são 10 grupos, tem bastante gente também.

A lista completa de grupos do telegram você encontra em gago.io/galera.

O que representam esses 10 anos?

Sendo muito prático, é uma conquista.

Ontem eu tive uma reunião com candidatos e novos alunos do Docker Definitivo e me surgiu a seguinte pergunta: “Porque você investe em Kong ao invés de investir no Ocelot?”

Essa pergunta sugere, que por conta de ser um projeto .NET, o Ocelot deveria ser privilegiado. A única referência que temos é a do EShopOnContainer e o aluno trouxe outra referência. A questão é que essa pergunta sugere o pensamento:

Ué, é tão óbvio que o padrão seria X, porque você está usando Y?

E minha defesa é a de que não existe opção default. Não existe esse tipo de bairrismo ao meu lado, defesa descabida. Da mesma forma que eu tenho críticas claras a 2 projetos sob o uso de mensageria. O Dapr e o próprio E-shopOnContainers.

Ambos, em busca de serem agnósticos fazem uso de abstrações que suprimem recursos e são obrigados a implementar em si, coisas que o RabbitMQ entrega de forma nativa. O viés causado pelo mindset do Azure Service Bus causa esse tipo de coisa, mas entendo que são decisões de design que não podem privilegiar vendor A, B ou C. Até o uso de pub/sub do redis, na minha opinião debuta contra o projeto.

Os espaços que produzo são desenhados para sairmos da caixa. Da mesma forma que não uso Ocelot por não achar que valha a pena, eu uso Squidex por achar que vale. Squidex é uma solução .net core.

Cada tecnologia, cada design tem de atender à um propósito, e as vezes o propósito é quebrar padrões mostrando o que está disponível. Mostrando quais soluções estão disponíveis para nós. Em outros momentos o propósito é apenas ter alguma das melhores ferramenta a um custo baixou ou nulo.

O grupo de arquitetura, hoje é tomado por posts e divulgação, mas esse foi o espaço que por anos sustentou diversas discussões incríveis. Algumas chegando ao nível da baixaria, inclusive.

Aliás, isso foi o que deu margem ao banner:

E é assim que quero conduzir os próximos passos, mesmo que não sabia quais serão.

Só uma fração do grupo participa das discussões

Embora a quantidade de pessoas seja grande nos grupos, é comum só uma fração dessas pessoas entrarem na discussão. Até porque seria impossível coordenar 3k pessoas discutindo um único tópico ao mesmo tempo.

A dinâmica dos grupos é a mesma de um coliseu.

Na arena, criadores, defensores de ideias, palpiteiros, geradores de confusão, hater, tem de tudo. Mas é sempre uma fração do grupo. A maioria sempre estará na arquibancada, olhando sem se comprometer com as discussões. Eles usam os argumentos de cada um como ponto de reflexão. E na real, poucos são os debatedores que realmente são capazes de mudar de ideia. Quem se beneficia de fato é a galera que está na arquibancada, olhando cada argumento e construindo uma ideia sobre o assunto. Alguns não entram na discussão por simples preguiça de ter de ficar alimentando a treta.

Então não necessariamente as discussões nos grupos são desenhadas pra contra-argumentar uma ideia, ou fazer um contraponto para o debatedor, há momentos que o que queremos é produzir o conjunto de argumentos que ajude quem está na plateia, quem de fato se beneficia e forma opinião de fato a partir dessas discussões.

E sobre a quantidade de gente participando das discussões, sempre será uma fração do grupo. Então se você pretende criar um grupo, não se frustre com isso.

O que podemos fazer é incentivar a galera nova. Não repelir, e tentar criar um ambiente que seja mais acolhedor, mas é importante ter em mente que só uma fração será de fato ativa no grupo.

Conclusão

Nesses 10 o maior desafio foi manter o grupo interessante para arquitetos. E nesses últimos anos, com o empenho da energia no telegram e o esforço que tenho empenhado no Docker Definitivo, tem sido cada vez pior.

Mas continuamos. Continuamos incentivando a criação de novos grupos, novas aglomerações virtuais para o debate de ideias.

Quanto mais, melhor!

Afinal, quem não gosta da minha gestão tem a chance de achar outros gestores de grupo que se identifiquem mais, e por aí vai.

Sobre o Arquitetura de Software .NET

Se você quer participar do grupo, quais são as regras:

1. Ter um perfil no linkedin
2. Seu perfil precisa indicar que você é um profissional de tecnologias Microsoft na ativa.
   1. Cargos de gestão, diretoria em geral desqualificam isso.
   2. Os cargos mais comuns são de Desenvolvedor, Lider Técnico, Arquiteto de Software e Arquiteto de Solução.
3. Ter 4 votos em uma única competência que ligue você à .NET. C#, ASP .NET, EF, NH…. Não vale a soma de 2 ou mais competências. Uma única competência precisa ter todos os 4 votos.

Nossas regras estão aqui: https://github.com/arquiteturadotnet/about

Essas exigências acima só existem para o grupo do Facebook.

No telegram não há exigência alguma.