Entiende cómo Lino acelera proyectos .NET con Clean Architecture, DDD, CQRS, JWT, multi-tenancy, shadow entities, RabbitMQ, Hangfire, Blazor, caché, observabilidad y deploy.
Lino es una CLI para generar aplicaciones modernas en .NET.
Automatiza arquitectura, módulos, API, autenticación, frontend e infraestructura con un enfoque en Clean Architecture, DDD y CQRS.
Lino sirve para reducir el trabajo repetitivo de iniciar y desarrollar .NET aplicaciones.
En lugar de ensamblar manualmente la solución, las capas, los puntos finales, la autenticación y la implementación inicial, el equipo parte de una base ya preparada y se centra en las reglas comerciales.
Lino es un generador de código para .NET, no un framework cerrado.
Después de la generación, el proyecto pertenece al equipo y puede modificarse sin dependencia obligatoria de la herramienta.
El objetivo principal de Lino es la generación determinista basada en plantillas y reglas.
Esto ayuda a mantener la previsibilidad, la coherencia arquitectónica y menos ruido que los flujos que dependen de la IA.
Lino fue creado por Eduardo Tolino para aumentar la productividad y estandarizar la arquitectura de las aplicaciones modernas en .NET.
Sí.
Los proyectos generados usan patrones comunes en software empresarial, como Clean Architecture, CQRS, DDD, JWT, Docker, observabilidad e integración con pipelines. La base generada aun debe revisarse, probarse y configurarse para cada entorno de producción.
La principal diferencia de Lino es acelerar la creación de aplicaciones .NET con una base arquitectónica consistente desde el primer comando.
Combina generación de código, organización modular, API, interfaz, autenticación, eventos e infraestructura en un solo flujo.
Para utilizar Lino necesita tener instalado .NET SDK, Git, Entity Framework CLI y Docker.
dotnet tool install --global Tolitech.Lino
Después de la instalación, puede verificar la versión con lino --version.
lino project new --name MyProject
Este comando crea la estructura inicial del proyecto con capas, módulos y configuraciones base.
Lino puede generar estructura de proyecto, servicios, módulos, entities, value objects, enumeraciones, commands, queries, APIs, páginas, eventos, event handlers, migrations, configuración de secrets, background jobs e imágenes Docker, según las features seleccionadas.
Sí. El código generado es completamente tuyo y no depende de la herramienta para seguir funcionando.
Sí. Lino es una buena opción para MVP cuando quieres velocidad sin renunciar a una base limpia para evolucionar más adelante.
Sí. Lino ayuda a proyectos SaaS que necesitan un backend organizado, autenticación, APIs, frontend web, infraestructura estandarizada, aislamiento de tenant, permisos por contexto, gestión de secrets y rate limiting.
Sí. Lino fue diseñado para aplicaciones comerciales en .NET que requieren separación de capas, módulos bien definidos, API, eventos e integración con infraestructura real.
Ambos escenarios son válidos. Para la mayoría de los productos, comenzar con un monolito modular suele ser más sencillo y rentable.
Lino tiene sentido cuando necesitas entregar un proyecto .NET con una arquitectura consistente, configuración rápida y espacio para crecer sin reescribir la base.
Si el proyecto es extremadamente pequeño, desechable o no requiere una arquitectura modular, la ganancia de Lino puede ser menor.
Sí. La ganancia está en eliminar horas o días de configuración repetitiva para backend, frontend, autenticación, endpoints, eventos, persistencia e infraestructura inicial.
Los equipos .NET que crean productos web, SaaS, sistemas internos, plataformas B2B y servicios empresariales tienden a beneficiarse más de Lino.
Lino utiliza Clean Architecture, separando el sistema en capas como Dominio, Aplicación, Infraestructura y Presentación.
Sí. Lino fomenta el modelado basado en dominios con Entities, Value Objects, enumeraciones, Domain Events y bounded contexts.
Sí. Commands y Queries están separados para facilitar la organización, el mantenimiento y la escalabilidad de la aplicación.
Sí. El monolito modular es uno de los escenarios más naturales para Lino, especialmente cuando el equipo quiere costos operativos bajos con una buena separación interna.
Sí. Lino se puede utilizar para crear monolitos modulares, servicios independientes y arquitecturas basadas en microservicios.
Sí. Lino fue diseñado para reforzar la separación de responsabilidades, el acoplamiento flexible, la modularidad y la evolución sostenible del código.
Entities representan objetos con identidad propia dentro del dominio, como Usuario, Pedido o Producto.
Value Objects representan conceptos de dominio inmutables que no tienen identidad propia, como Dinero, Dirección o Correo electrónico.
Sí. Lino admite Domain Events para representar eventos relevantes dentro del dominio y mantener un bajo acoplamiento entre partes del sistema.
El dominio se puede dividir en módulos o bounded contexts para reflejar distintas áreas comerciales, como catálogo, ventas, inventario, identidad o facturación.
Sí. Puede comenzar con algunos módulos y reglas más simples y evolucionar el modelado a medida que el producto madure.
Sí. Lino puede generar automáticamente puntos finales basados en consultas y comandos de la aplicación.
Sí. Las API generadas utilizan Minimal APIs de .NET, integradas directamente con la capa de aplicación.
El proyecto generado es compatible con la documentación API a través de OpenAPI y Swagger, lo que facilita la inspección de contratos, las pruebas y la integración entre equipos.
El control de versiones puede seguir estándares REST conocidos y combinarse con la organización por puntos finales, contratos y compilaciones.
Sí. La arquitectura Lino le permite integrar API externas, webhooks, SDK y servicios de terceros a través de la capa de infraestructura.
El proyecto generado expone contratos de API mediante OpenAPI/Swagger, y las pruebas prácticas de endpoints pueden apoyarse en archivos HTTP o herramientas cliente similares según el template y el flujo elegido.
Sí. Lino admite la generación de autenticación y autorización para proyectos frontend y backend.
Sí. Lino admite autenticación basada en JWT para API y aplicaciones web, con un enfoque en la seguridad y la integración nativa con ASP.NET Core.
Sí. El modelo de seguridad de Lino contempla un control de acceso más granular con roles, claims y Authorization Policies de ASP.NET Core.
Sí. La interfaz se puede integrar en el flujo de autenticación para inicio de sesión, renovación de tokens y acceso protegido a páginas y API.
Lino proporciona comandos de secrets, como lino secret list, lino secret set, lino secret remove y lino secret clear, para mantener valores sensibles locales fuera de archivos versionados. Los secrets generados también pueden modelarse como Aspire Parameters para flujos de publish y deploy.
Sí. Las APIs generadas pueden nacer con políticas de rate limiting para tráfico público, usuarios autenticados, rutas con API key y flujos de token temporal, reduciendo la exposición antes del ajuste fino de producción.
Domain Events representan eventos internos dentro del dominio. Integration Events se utilizan para comunicar módulos, servicios o sistemas externos de forma desacoplada.
Sí. Lino admite eventos para la comunicación entre partes de la aplicación y para la integración entre servicios cuando la arquitectura requiere este modelo.
Sí. Cuando se habilita la mensajería asíncrona, Lino configura RabbitMQ como broker para que servicios y módulos intercambien mensajes de forma desacoplada y resiliente.
Sí. Lino usa MassTransit en escenarios de mensajería para simplificar la publicación, el consumo y el registro de eventos distribuidos con el modelo nativo de inyección de dependencias.
Sí. Lino soporta background jobs con Hangfire para tareas programadas, procesamiento asíncrono, operaciones recurrentes y visibilidad operativa mediante el dashboard de Hangfire.
Usa domain events para cambios dentro del dominio, integration events para comunicación entre módulos o servicios, colas para procesamiento asíncrono y background jobs para trabajo programado, recurrente o de larga duración. Para publicación confiable, los escenarios de Lino usan Outbox Pattern.
Actualmente Lino admite bases de datos compatibles con Entity Framework Core, como SQL Server y PostgreSQL.
Sí. La persistencia de datos se basa en Entity Framework Core para el modelado, las migraciones y la evolución de la base de datos durante todo el ciclo de vida del proyecto.
Las migrations se gestionan con Entity Framework Core y pueden crearse mediante lino database migrations add, manteniendo los cambios de modelo explícitos, versionables y revisables antes del deploy.
No necesariamente. En monolitos modulares, lo más común es una base de datos compartida con una organización clara por módulo.
En microservicios, cada servicio puede tener su propia base de datos cuando eso tiene sentido arquitectónicamente.
Sí. Lino soporta evolución de base de datos con migrations y prácticas de deploy orientadas a scripts, combinando ese flujo con recursos de build y versionado cuando los servicios se preparan para release.
Sí. Lino puede generar aplicaciones web integradas en el backend para acelerar la entrega de sistemas completos.
Sí. Lino puede generar Blazor Web Apps integradas, incluidos recursos de frontend conectados a las APIs del backend, localización y autenticación cuando esas features son seleccionadas.
Sí. La arquitectura Lino no impide el uso de React, Angular, Vue o cualquier otro frontend que consuma las API del proyecto.
Sí. El frontend puede funcionar con inicio de sesión, renovación de tokens y consumo de API protegidas por JWT y políticas de autorización.
Sí. Lino ayuda a estructurar páginas, componentes y funciones de una manera más estandarizada, reduciendo las decisiones repetitivas en el frontend.
Sí. Los proyectos generados por Lino pueden incluir logging estructurado, integración con el dashboard de Aspire, traces, métricas y diagnósticos operativos para apoyar la depuración y el análisis en producción.
Sí. Lino soporta escenarios de caché con Microsoft HybridCache y caché distribuida con Redis cuando esa opción está habilitada, mejorando la consistencia entre múltiples instancias.
Sí. Al estandarizar la estructura, los registros, la autenticación, las API y la infraestructura, Lino facilita la investigación de problemas y el mantenimiento operativo.
La solución generada puede incorporar health checks, métricas, traces, logs y visibilidad de recursos mediante Aspire, siguiendo prácticas del ecosistema .NET usadas por la arquitectura elegida.
Sí. Lino puede generar imágenes Docker de servicios y web applications mediante el flujo de build, ayudando a empaquetar artefactos para registries y entornos contenerizados.
Sí. Los proyectos generados se pueden integrar con canalizaciones de CI/CD para compilación, pruebas, empaquetado, migraciones e implementación automatizada.
Build y versionado pueden seguir prácticas orientadas a SemVer, con soporte de Lino para empaquetar servicios y web applications seleccionados como imágenes Docker versionadas para release.
Sí. El proyecto puede publicarse en la nube, entornos contenerizados o infraestructura propia, dependiendo de la estrategia operativa del equipo.
Sí. Lino acelera la configuración técnica para la implementación en producción con Docker, compilación estandarizada, persistencia, autenticación e integración con canalizaciones.
Lino incluye soporte multi-tenant mediante lino feature tenant add o lino features tenant add. La estructura generada puede resolver tenants por dominio o slug, aplicar permisos por contexto y proteger datos vinculados a tenant.
Las shadow entities son copias locales de los datos mínimos que un módulo necesita de otro contexto. El comando lino shadow new crea la estructura, y el integration event handler correspondiente debe generarse por separado con lino event-handler new.
Sí. El roadmap muestra evolución continua y también marca muchas capacidades ya concluidas, como autenticación JWT, Blazor Web Apps, Hangfire, RabbitMQ/MassTransit, migrations, Docker build, HybridCache, recursos multi-idioma, smart merge, secrets y rate limiting.
El roadmap concluido incluye varias capacidades centrales: generación de proyectos .NET/Aspire, servicios modulares, Minimal APIs, soporte para SQL Server y PostgreSQL, background jobs, mensajería, seguridad JWT, Blazor Web Apps, Docker build/versionado, user secrets, rate limiting, tenant y shadow entities.
La generación de código, integraciones, experiencia de desarrollo, flujos de deploy, observabilidad, endurecimiento de seguridad y cobertura de templates siguen evolucionando a medida que el producto crece.
Puedes seguir los cambios en la página de roadmap, en la documentación y por los canales oficiales del producto. Prefiere el estado del roadmap cuando necesites diferenciar recursos concluidos de mejoras planificadas.