Entenda como o Lino acelera projetos .NET com Clean Architecture, DDD, CQRS, JWT, multi-tenancy, shadow entities, RabbitMQ, Hangfire, Blazor, cache, observabilidade e deploy.
O Lino é uma CLI para geração de aplicações modernas em .NET.
Ela automatiza arquitetura, módulos, APIs, autenticação, frontend e infraestrutura com foco em Clean Architecture, DDD e CQRS.
O Lino serve para reduzir o trabalho repetitivo de iniciar e evoluir aplicações .NET.
Em vez de montar manualmente solução, camadas, endpoints, autenticação e deploy inicial, o time parte de uma base pronta e foca nas regras de negócio.
O Lino é um gerador de código para .NET, não um framework fechado.
Depois da geração, o projeto pertence ao time e pode ser modificado sem dependência obrigatória da ferramenta.
O foco principal do Lino é geração determinística baseada em templates e regras.
Isso ajuda a manter previsibilidade, consistência arquitetural e menos ruído do que fluxos dependentes de IA.
O Lino foi criado por Eduardo Tolino para aumentar produtividade e padronizar a arquitetura de aplicações modernas em .NET.
Sim.
Os projetos gerados usam padrões comuns em software corporativo, como Clean Architecture, CQRS, DDD, JWT, Docker, observabilidade e integração com pipelines. A base gerada ainda deve ser revisada, testada e configurada para cada ambiente de produção.
O principal diferencial do Lino é acelerar a criação de aplicações .NET com uma base arquitetural consistente desde o primeiro comando.
Ele combina geração de código, organização modular, APIs, frontend, autenticação, eventos e infraestrutura em um fluxo único.
Para usar o Lino você precisa ter instalado .NET SDK, Git, Entity Framework CLI e Docker.
dotnet tool install --global Tolitech.Lino
Depois da instalação você pode verificar a versão com lino --version.
lino project new --name MyProject
Esse comando cria a estrutura inicial do projeto com camadas, módulos e configurações base.
O Lino pode gerar estrutura de projeto, serviços, módulos, entidades, value objects, enumerações, commands, queries, APIs, páginas, eventos, event handlers, migrations, configuração de segredos, background jobs e imagens Docker, conforme as features selecionadas.
Sim. O código gerado é totalmente seu e não depende da ferramenta para continuar funcionando.
Sim. O Lino é uma boa opção para MVP quando você quer velocidade sem abrir mão de uma base limpa para evoluir depois.
Sim. O Lino ajuda projetos SaaS que precisam de backend organizado, autenticação, APIs, frontend web, infraestrutura padronizada, isolamento de tenant, permissões por contexto, gerenciamento de segredos e rate limiting.
Sim. O Lino foi pensado para aplicações empresariais em .NET que exigem separação de camadas, módulos bem definidos, APIs, eventos e integração com infraestrutura real.
Os dois cenários são válidos. Para a maioria dos produtos, começar com monólito modular costuma ser mais simples e econômico.
O Lino faz sentido quando você precisa entregar um projeto .NET com arquitetura consistente, rapidez de setup e espaço para crescer sem reescrever a base.
Se o projeto for extremamente pequeno, descartável ou não precisar de arquitetura modular, o ganho do Lino pode ser menor.
Sim. O ganho está em eliminar horas ou dias de setup repetitivo para backend, frontend, autenticação, endpoints, eventos, persistência e infraestrutura inicial.
Times .NET que constroem produtos web, SaaS, sistemas internos, plataformas B2B e serviços empresariais costumam se beneficiar mais do Lino.
O Lino utiliza Clean Architecture, separando o sistema em camadas como Domain, Application, Infrastructure e Presentation.
Sim. O Lino incentiva modelagem baseada em domínio com Entities, Value Objects, Enums, Domain Events e bounded contexts.
Sim. Commands e Queries são separados para facilitar organização, manutenção e escalabilidade da aplicação.
Sim. O monólito modular é um dos cenários mais naturais para o Lino, principalmente quando o time quer baixo custo operacional com boa separação interna.
Sim. O Lino pode ser usado para criar monólitos modulares, serviços independentes e arquiteturas baseadas em microserviços.
Sim. O Lino foi desenhado para reforçar separação de responsabilidades, baixo acoplamento, modularidade e evolução sustentável do código.
Entities representam objetos com identidade própria dentro do domínio, como User, Order ou Product.
Value Objects representam conceitos imutáveis do domínio que não possuem identidade própria, como Money, Address ou Email.
Sim. O Lino suporta Domain Events para representar acontecimentos relevantes dentro do domínio e manter baixo acoplamento entre partes do sistema.
O domínio pode ser dividido em módulos ou bounded contexts para refletir áreas de negócio distintas, como catálogo, vendas, estoque, identidade ou faturamento.
Sim. Você pode começar com poucos módulos e regras mais simples e evoluir a modelagem à medida que o produto amadurece.
Sim. O Lino pode gerar endpoints automaticamente baseados em comandos e queries da aplicação.
Sim. As APIs geradas utilizam Minimal APIs do .NET, integradas diretamente com a camada de aplicação.
O projeto gerado é compatível com documentação de APIs via OpenAPI e Swagger, o que facilita inspeção de contratos, testes e integração entre times.
O versionamento pode seguir padrões REST conhecidos e ser combinado com organização por endpoints, contratos e builds.
Sim. A arquitetura do Lino permite integrar APIs externas, webhooks, SDKs e serviços de terceiros através da camada de infraestrutura.
O projeto gerado expõe contratos de API por OpenAPI/Swagger, e testes práticos de endpoints podem ser apoiados por arquivos HTTP ou ferramentas clientes semelhantes conforme o template e o fluxo escolhido.
Sim. O Lino possui suporte à geração de autenticação e autorização para projetos frontend e backend.
Sim. O Lino suporta autenticação baseada em JWT para APIs e aplicações web, com foco em segurança e integração nativa com ASP.NET Core.
Sim. O modelo de segurança do Lino contempla controle mais granular de acesso com roles, claims e Authorization Policies do ASP.NET Core.
Sim. O frontend pode ser integrado ao fluxo de autenticação para login, renovação de token e acesso protegido a páginas e APIs.
O Lino fornece comandos de secrets, como lino secret list, lino secret set, lino secret remove e lino secret clear, para manter valores sensíveis locais fora de arquivos versionados. Segredos gerados também podem ser modelados como Aspire Parameters para fluxos de publish e deploy.
Sim. APIs geradas podem nascer com políticas de rate limiting para tráfego público, usuários autenticados, rotas com API key e fluxos de token temporário, reduzindo exposição antes do ajuste fino de produção.
Domain Events representam acontecimentos internos do domínio. Integration Events servem para comunicar módulos, serviços ou sistemas externos de forma desacoplada.
Sim. O Lino suporta eventos para comunicação entre partes da aplicação e para integração entre serviços quando a arquitetura exige esse modelo.
Sim. Quando a mensageria assíncrona é habilitada, o Lino configura RabbitMQ como broker para que serviços e módulos troquem mensagens de forma desacoplada e resiliente.
Sim. O Lino usa MassTransit em cenários de mensageria para simplificar publicação, consumo e registro de eventos distribuídos com o modelo nativo de injeção de dependência.
Sim. O Lino suporta background jobs com Hangfire para tarefas agendadas, processamento assíncrono, operações recorrentes e visibilidade operacional pelo dashboard do Hangfire.
Use domain events para mudanças dentro do domínio, integration events para comunicação entre módulos ou serviços, filas para processamento assíncrono e background jobs para trabalho agendado, recorrente ou demorado. Para publicação confiável, cenários do Lino usam Outbox Pattern.
Atualmente o Lino suporta bancos compatíveis com Entity Framework Core, como SQL Server e PostgreSQL.
Sim. A persistência de dados é baseada em Entity Framework Core para modelagem, migrations e evolução do banco ao longo do ciclo de vida do projeto.
Migrations são gerenciadas com Entity Framework Core e podem ser criadas por lino database migrations add, mantendo alterações de modelo explícitas, versionáveis e revisáveis antes do deploy.
Não necessariamente. Em monólitos modulares o mais comum é um banco compartilhado com organização clara por módulo.
Em microserviços, cada serviço pode ter seu próprio banco quando isso fizer sentido arquiteturalmente.
Sim. O Lino suporta evolução de banco com migrations e práticas de deploy orientadas a scripts, combinando esse fluxo com recursos de build e versionamento quando serviços são preparados para release.
Sim. O Lino pode gerar aplicações web integradas ao backend para acelerar a entrega de sistemas completos.
Sim. O Lino pode gerar Blazor Web Apps integradas, incluindo recursos de frontend conectados às APIs do backend, localização e autenticação quando essas features são selecionadas.
Sim. A arquitetura do Lino não impede usar React, Angular, Vue ou qualquer outro frontend que consuma as APIs do projeto.
Sim. O frontend pode trabalhar com login, renovação de token e consumo de APIs protegidas por JWT e políticas de autorização.
Sim. O Lino ajuda a estruturar páginas, componentes e features de forma mais padronizada, reduzindo decisões repetitivas no frontend.
Sim. Projetos gerados pelo Lino podem incluir logging estruturado, integração com dashboard do Aspire, traces, métricas e diagnósticos operacionais para apoiar depuração e análise em produção.
Sim. O Lino suporta cenários de cache com Microsoft HybridCache e cache distribuído com Redis quando essa opção é habilitada, melhorando consistência entre múltiplas instâncias.
Sim. Ao padronizar estrutura, logs, autenticação, APIs e infraestrutura, o Lino facilita investigação de problemas e manutenção operacional.
A solução gerada pode incorporar health checks, métricas, traces, logs e visibilidade de recursos pelo Aspire, seguindo práticas do ecossistema .NET usadas pela arquitetura escolhida.
Sim. O Lino pode gerar imagens Docker de serviços e web applications pelo fluxo de build, ajudando a empacotar artefatos para registries e ambientes conteinerizados.
Sim. Os projetos gerados podem ser integrados com pipelines de CI/CD para build, testes, empacotamento, migrations e deploy automatizado.
Build e versionamento podem seguir práticas orientadas a SemVer, com suporte do Lino para empacotar serviços e web applications selecionados como imagens Docker versionadas para release.
Sim. O projeto pode ser publicado em cloud, ambientes com containers ou infraestrutura própria, conforme a estratégia de operação do time.
Sim. O Lino acelera o setup técnico para deploy em produção com Docker, build padronizado, persistência, autenticação e integração com pipelines.
O Lino inclui suporte multi-tenant por lino feature tenant add ou lino features tenant add. A estrutura gerada pode resolver tenants por domínio ou slug, aplicar permissões por contexto e proteger dados vinculados a tenant.
Shadow entities são cópias locais dos dados mínimos que um módulo precisa de outro contexto. O comando lino shadow new cria a estrutura, e o event handler de integração correspondente deve ser gerado separadamente com lino event-handler new.
Sim. O roadmap mostra evolução contínua e também marca muitas capacidades já concluídas, como autenticação JWT, Blazor Web Apps, Hangfire, RabbitMQ/MassTransit, migrations, Docker build, HybridCache, recursos multi-idioma, smart merge, secrets e rate limiting.
O roadmap concluído inclui várias capacidades centrais: geração de projetos .NET/Aspire, serviços modulares, Minimal APIs, suporte a SQL Server e PostgreSQL, background jobs, mensageria, segurança JWT, Blazor Web Apps, Docker build/versionamento, user secrets, rate limiting, tenant e shadow entities.
Geração de código, integrações, experiência de desenvolvimento, fluxos de deploy, observabilidade, endurecimento de segurança e cobertura de templates continuam evoluindo conforme o produto cresce.
Você pode acompanhar mudanças pela página de roadmap, pela documentação e pelos canais oficiais do produto. Prefira o status do roadmap quando precisar diferenciar recursos concluídos de melhorias planejadas.