Arquitetura

Arquiteto Web

Professor Universitário

Guilherme Siquinelli

Co-fundador da DevParaná

Programador desde os 13

/ guiseek

/ guiseek

Mentor pela comunidade

Nx Champion

Gosto de...

Pensar

, aprender

, ensinar

, escrever,

programar

, meditar

, filosofar

, desenhar, 

produzir

, brincar

, jogar

, editar

, explorar,

questionar

, viajar

, quebrar

, pesquisar,

testar

, consertar

, observar

, mudar

compartilhar.

e

Crescimento da equipe de engenharia

Fonte: Arquitetura Limpa, Robert C. Martin (Uncle Bob)

eixo vertical: equipe de engenharia - eixo horizontal: releases

Produtividade durante o mesmo período

Fonte: Arquitetura Limpa, Robert C. Martin (Uncle Bob)

eixo vertical: tamanho do produto - eixo horizontal: releases

Produtividade

Fonte: Arquitetura Limpa, Robert C. Martin (Uncle Bob)

Folha de pagamento mensal

Fonte: Arquitetura Limpa, Robert C. Martin (Uncle Bob)

Hard

  • Organização

  • Manutenção

  • Desempenho

  • Complexidade

Soft

  • Comunicação

  • Entendimento

  • Estimativas

  • Planejamento

Prazo

Escopo

Pessoas

Carpe Diem

Prazer, amanhã.

The future is still

so much bigger

than the past.

- Sir Tim Berners-Lee

Princípios de Design de Classes Orientado a Objetos

  1. Aberto-Fechado

  2. Substituição de Liskov

  3. Inversão de Dependência

  4. Segregação de Interface

  5. Responsabilidade Única

Técnicas e soluções

Arquitetura limpa

Padronizar e organizar o código, favorecendo o reuso, independente de tecnologia ou solução

“Uma boa arquitetura torna o sistema fácil de entender, fácil de desenvolver, fácil de manter e fácil de implantar. O objetivo final é minimizar o custo de vida útil do sistema e maximizar a produtividade do programador.”


― Robert C. Martin,  Arquitetura Limpa

Camadas

As diferentes áreas de um software devem estar em lugares diferentes

domain

domain

data

ui

As camadas favorecem

  • Escrita de testes
  • Independência de UI
  • Independência de DB
  • Entre outras independências...

Soft

ware

Suave 

 produto

monorepo !== monolito

  • Simplifica o compartilhamento de código
  • Facilita refatorações entre projetos
  • Reduz o custo na criação de novas bibliotecas, micro serviços e microfrontends.

Portanto, a adoção de um monorepo geralmente permite mais flexibilidade de implantação.

O monorepo

Mono repositório

Um repositório único com vários projetos distintos e relacionamentos bem definidos entre eles

Não é colocar código

Considere um repositório com vários projetos nele.

Se não houver relacionamentos bem definidos entre eles, não o chamaríamos de monorepo.

Chamamos de monorepo se

Projetos dependem uns dos outros, para que possam compartilhar código.

Em alterações, não "buildamos" nem testamos todos os projetos, apenas executamos novamente projetos que podem ser afetados pela alteração em questão...

<em>

</em>

Ênfase pois

Isso torna o CI mais rápido, em grande escala isso pode significar 1000 vezes mais rápido.

Dá independência às equipes que estão trabalhando.

Se o projeto A e B não dependem um do outro, eles não podem afetar um ao outro – nunca.

Mas...

Nada é perfeito

E eles vêm com seus próprios desafios.

Trunk based

trunkbaseddevelopment.com/monorepos

mais informações em:

Suporte em serviços

Nem todos os serviços funcionam com ele

🤔

Monorepos

Polyrepos

😁

Polyrepos

Compartilhamento de código complicado

Cada novo repo significa:

  • Configurar as ferramentas
  • Configurar ambiente de CI
  • Adicionar committers
  • Configurar a publicação

Isso, esquecendo versões incompatíveis de bibliotecas de terceiros entre eles...

Duplicação de código significativa

Cada novo repo significa:

  • Diferentes implementações
  • Desperdício de tempo
  • Maior carga de manutenção
  • Controle de qualidade

Geralmente repositórios compartilhados acabam por ficar orfãos

Entre outros problemas

  • Alterações caras entre repositórios em bibliotecas e consumidores compartilhados
  • Ferramental inconsistente
  • E por aí vai...

😃

Monorepos

Sem sobrecarga para criar novos projetos

Com monorepo significa:

  • Reuso de implementações
  • Mesma configuração de CI
  • Não precisa publicar pacotes
  • Maior controle de qualidade

E nem falamos nas facilidades em novos apps e pacotes usando geradores

Commits atômicos entre projetos

Com monorepo significa:

  • Funcionando em conjunto
  • Sem break changes locais
  • Ambientes integrados
  • Maior controle de qualidade²

Entre outros benefícios

  • Uma versão de tudo
  • Mobilidade do desenvolvedor
  • E por aí vai...

Arquitetura limpa

mono
repositórios

♥️

Independência é

A equipe A poderá desenvolver seu projeto, testa-lo, mesclar PR's na main sem nunca precisar executar nenhum código escrito pela equipe B.

Portanto, a equipe B pode ter testes irregulares, código mal escrito ou quebrando testes, nada disso importa para a equipe A.

Library Types

Tipos de bibliotecas

Definição de camadas

Ui


Data
 



Domain

Só isso?!

Não

Convenções para monorepos

  • Feature libraries
  • UI libraries
  • Data-access libraries
  • Utility libraries
     
  • Resource libraries
  • Data-source libraries

Feature-*

Bibliotecas que implementam UI inteligentes...

  • Acesso a fontes de dados.
  • Para casos de uso de negócios.
  • Ou páginas em um aplicativo.

Ui-*

Contém apenas componentes de apresentação ou "burros"...

  • Sem casos de uso de negócios.
  • Elementos reaproveitáveis

Data-access

Biblioteca de acesso a dados contém código para interagir com um sistema de back-end.

Também inclui todo o código relacionado à gestão do estado.

  • +Store
  • Application
  • Infrastructure

Util-*

Contém utilitários de baixo nível usados por muitas bibliotecas e aplicativos.

  • Funções puras
  • Classes de encapsulamento...

domain

domain

data

ui

styles, components

services, facades

repo, usecases

entities, dtos

Todas essas camadas

Isso não demanda muito?

não...

{
  "name": "@meetup/source",
  "version": "0.0.0",
  "license": "MIT",
  "scripts": {},
  "private": true,
  "dependencies": {},
  "devDependencies": {
    "@nx/js": "19.0.6",
    "@nx/workspace": "19.0.6",
    "nx": "19.0.6"
  }
}

Criando uma biblioteca

Criando um gerador

Gerador customizado

Governança

Ok, mas...

Como garantir que as pessoas respeitarão?

Relacionamentos

Podemos definir relações entre projetos, e isso é de extrema importância para que todas as equipes que trabalham no repositório continuem seguindo os padrões estabelecidos.

{
  "enforceBuildableLibDependency": true,
  "allow": [],
  "depConstraints": [
    {
      "sourceTag": "type:data",
      "onlyDependOnLibsWithTags": [
      	"type:domain"
      ]
    },
    {
      "sourceTag": "type:domain",
      "onlyDependOnLibsWithTags": [
      	"type:util"
       ]
    },
    {
      "sourceTag": "type:ui",
      "onlyDependOnLibsWithTags": [
      	"type:ui",
        "type:util"
      ]
    },
    {
      "sourceTag": "type:util",
      "onlyDependOnLibsWithTags": [
      	"type:util"
      ]
    },
    {
      "sourceTag": "type:feature",
      "onlyDependOnLibsWithTags": [
        "type:data",
        "type:ui",
        "type:util"
      ]
    },
    {
      "sourceTag": "type:shell",
      "onlyDependOnLibsWithTags": [
        "type:feature",
        "type:data",
        "type:ui",
        "type:util"
      ]
    },
    {
      "sourceTag": "type:app",
      "onlyDependOnLibsWithTags": [
        "type:shell",
        "type:feature",
        "type:domain",
        "type:data",
        "type:ui",
        "type:util"
      ]
    }
  ]
}

Definindo

CODEOWNERS

GitHub ✔

GitHub Doc

Dependências

Report gráfico

Perguntas?

Obrigado

😌
🙏

Made with Slides.com