Saltar al contenido principal

Taxonomía básica de artefactos de software

Metadatos de la lección

Autoría:
Ignacio Slater-Muñoz
Última actualización:
31 de marzo de 2026

Cambios recientes:

  • 4ba9211 · 31 de marzo de 2026 · 📝✨ feat(unit-1): add software artifacts taxonomy lesson ( GitLab / GitHub )

Abstract

Esta lección abre la unidad con una pregunta previa a cualquier decisión de diseño: qué estamos construyendo y para quién. Antes de profundizar en bibliotecas, conviene distinguir el mapa más amplio donde también aparecen aplicaciones, scripts, herramientas, plugins y paquetes.

La meta no es memorizar etiquetas, sino fijar un criterio para leer el resto del curso. Cuando entendemos qué cambia en la forma de consumo, en el contrato y en la distribución de estos artefactos, se vuelve más claro qué hace particular a la biblioteca como forma de reutilización programática.

¿Qué es un artefacto de software?

Antes de distinguir biblioteca, aplicación, script, herramienta o paquete, conviene fijar el concepto más amplio que las contiene. Las categorías que siguen son distintos tipos de artefacto de software, no etiquetas aisladas.

Un artefacto de software es una unidad de software que puede producirse, distribuirse y consumirse dentro de un ecosistema técnico. No es solo un archivo o ejecutable, sino una unidad con propósito, forma de consumo y expectativas de uso.

Lo importante no es solo cómo está implementado, sino qué relación de uso establece con otras personas o sistemas. Por eso esta lección se organiza alrededor de una pregunta práctica: ¿qué artefacto estamos diseñando y para quién?

Por qué hace falta distinguir artefactos

En conversaciones técnicas es común usar palabras como biblioteca, herramienta o script como si fueran casi sinónimos. Sin embargo, cada una apunta a una relación de uso distinta. Cambia quién consume el artefacto, cómo lo hace, qué tipo de estabilidad espera y qué tan explícito debe ser su contrato.

Esa diferencia importa porque el diseño no depende únicamente de la funcionalidad interna, sino también de la interfaz de uso que se ofrece hacia afuera. Una biblioteca se evalúa por la claridad y estabilidad de su API; una aplicación, por la experiencia de uso final; un script, por resolver una tarea concreta con la menor fricción posible.

Misma implementación, distinto artefacto

Dos soluciones pueden compartir gran parte del mismo código y aun así constituir artefactos distintos. Lo decisivo no es solo la lógica interna, sino la forma de consumo que se diseña y el contrato que se promete hacia afuera.

Fijar esta distinción desde el comienzo evita mezclar preguntas diferentes. No es lo mismo automatizar una tarea local, empaquetar una herramienta para un equipo o publicar una biblioteca para que otras personas la integren en sus programas. Esa diferencia afecta decisiones de distribución, documentación, validación y mantenimiento.

Definiciones operativas

En esta lección, la distinción base se centra en formas de consumo: biblioteca, aplicación, script y herramienta. Además, se incorporan dos dimensiones complementarias: plugin como extensión de un anfitrión y paquete como unidad de distribución.

Biblioteca

Una biblioteca está diseñada para ser integrada desde código de otro programa mediante una API. A diferencia de una aplicación o herramienta, su foco no es la operación directa, sino la reutilización programática. Ejemplos claros son kotlinx.coroutines y kotlinx.serialization en el ecosistema Kotlin, o Requests, biblioteca HTTP de Python.

Aplicación

Una aplicación está orientada al uso directo por parte de personas usuarias finales. A diferencia de una biblioteca, su contrato principal es la experiencia de uso final, no la API para integración. Una app Android escrita en Kotlin o Visual Studio Code son ejemplos de artefactos que se evalúan como producto final.

Script

Un script suele orientarse a automatizar una tarea concreta en un contexto local o acotado. A diferencia de una herramienta compartida, normalmente prioriza bajo costo de arranque sobre un contrato público estable. build.gradle.kts actúa como script dentro de Gradle, y backup.ps1 o rename_photos.py representan automatizaciones locales típicas.

Herramienta

Una herramienta es un artefacto pensado para ser operado por otras personas o equipos con interfaz técnica definida. A diferencia de un script local, ya exige instalación, documentación y comportamiento repetible para terceros. Gradle, ktlint y detekt son ejemplos del ecosistema Kotlin/JVM; ripgrep es un ejemplo general muy conocido.

Plugin

Un plugin extiende el comportamiento de un artefacto anfitrión mediante puntos de extensión definidos por ese anfitrión. A diferencia de una biblioteca general, no se integra desde código arbitrario en cualquier contexto, sino dentro del ciclo de vida de la plataforma que lo carga. Un plugin de Gradle o un plugin de IntelliJ IDEA son ejemplos típicos.

Paquete

Un paquete también es un artefacto, pero su eje principal es la distribución. A diferencia de una biblioteca (integración desde código) y de un plugin (extensión de un anfitrión), no describe primero una relación de uso, sino una unidad de entrega en un ecosistema. Un artefacto publicado en Maven Central, un paquete descrito por package.json o un paquete de Cargo son ejemplos de esta lógica de distribución.

Regla rápida

Si la pregunta principal es cómo otras personas lo invocan, lo operan o lo integran, probablemente estás distinguiendo entre biblioteca, aplicación, herramienta o script. Si la pregunta principal es cómo se distribuye, probablemente estás hablando de paquete.

Estas categorías no son excluyentes

Un mismo proyecto puede combinar varias de estas dimensiones. Por ejemplo, un paquete puede distribuir una biblioteca y, además, incluir una herramienta de línea de comandos apoyada en esa misma biblioteca.

Comparación por ejes

Una vez instalado artefacto como marco conceptual, una forma útil de comparar sus variantes es mirar siempre los mismos ejes. Así la distinción no depende solo de intuiciones vagas, del tamaño del proyecto o de detalles accidentales de la implementación. Estos ejes no producen categorías rígidas, pero ayudan a ver qué tipo de contrato y mantenimiento exige cada artefacto.

Destinatario principal

  • Biblioteca: otras personas desarrolladoras.
  • Aplicación: personas usuarias finales.
  • Script: quien automatiza una tarea local o de equipo.
  • Herramienta: otras personas o equipos que necesitan operar una capacidad concreta.

Modo de consumo

  • Biblioteca: integración desde código, importación o uso de una API pública.
  • Plugin: carga por un anfitrión mediante puntos de extensión definidos.
  • Aplicación: interfaz gráfica, web, móvil o consola interactiva; el foco está en la experiencia de uso final, no en la operación técnica.
  • Script: ejecución directa desde terminal o intérprete.
  • Herramienta: comandos, flags, archivos de entrada y salida o flujos operacionales definidos.

Contrato visible

El contrato cambia según el ejemplo: en kotlinx.serialization se espera estabilidad de API; en ktlint o detekt se espera operación consistente, opciones claras y salida interpretable.

  • Biblioteca: nombres, tipos, semántica, errores, compatibilidad.
  • Plugin: compatibilidad con la API de extensión del anfitrión y su ciclo de vida.
  • Aplicación: comportamiento visible, experiencia de uso y resultados funcionales.
  • Script: liviano; basta con que la tarea sea clara y predecible para su contexto.
  • Herramienta: interfaz de uso, documentación, instalación, mensajes de error y comportamiento repetible.

Estabilidad esperada

En la práctica, una biblioteca publicada para terceros en Maven Central suele exigir más cuidado de compatibilidad que un script local como backup.ps1.

  • Biblioteca: alta; cambios controlados, versionado y cuidado de compatibilidad.
  • Aplicación: puede cambiar internamente sin exponer cada detalle como contrato programático.
  • Script: baja; alcance local y menor presión por estabilidad pública.
  • Herramienta: alta; ya circula entre personas distintas y exige operación repetible por terceros.

Distribución

Este eje se entiende rápido al contrastar una biblioteca distribuida por Maven Central con una aplicación descargable mediante instalador o tienda.

  • Biblioteca: suele viajar dentro de paquetes o repositorios de dependencias.
  • Aplicación: instaladores, despliegues o publicación como producto listo para usarse.
  • Script: archivo o conjunto pequeño de archivos compartidos de forma acotada.
  • Herramienta: binarios, paquetes, repositorios internos o canales de instalación compartidos.

El paquete cruza a las otras categorías

Biblioteca, aplicación, script y herramienta describen principalmente una relación de uso. En cambio, paquete describe sobre todo una forma de distribución. En el ecosistema JVM, un artefacto publicado en Maven Central puede distribuir una biblioteca, y un plugin publicado en el Gradle Plugin Portal puede circular como paquete. En ese caso, plugin nombra la relación de extensión con su anfitrión; paquete, su forma de distribución.

Casos comparativos

De script local a herramienta compartida

Imagina un script que renombra archivos para una necesidad puntual del entorno local. Mientras solo lo use quien lo escribió, puede bastar con que funcione en su máquina y con algunos supuestos implícitos sobre rutas, nombres o permisos, porque todavía no existe una promesa de uso hacia otras personas.

El escenario cambia cuando otras personas del equipo empiezan a depender de ese mismo resultado. En ese momento ya no basta con que el script funcione: hace falta pensar en instalación, mensajes de error, parámetros claros, comportamiento repetible y documentación de uso. La lógica puede seguir siendo similar, pero el artefacto ya no se evalúa como script local, sino como una herramienta compartida.

El cambio importante no es de tamaño, sino de contrato. La pregunta ya no es solo si automatiza algo útil, sino si otra persona puede usarlo con confianza sin depender de conocer la implementación. A partir de ahí, importa menos que la automatización exista y más que su uso sea claro, repetible y predecible.

Biblioteca publicada en un paquete y consumida por una aplicación

Considera kotlinx.serialization como biblioteca reutilizable en proyectos Kotlin/JVM. Su API está pensada para otras personas desarrolladoras, por lo que el foco está en nombres claros, tipos coherentes y comportamiento estable.

Para circular en el ecosistema, esa biblioteca se distribuye como paquete en Maven Central. El paquete no reemplaza a la biblioteca ni la redefine: solo la transporta con versión, metadatos y dependencias. Luego, una aplicación, por ejemplo una app Android en Kotlin, instala ese paquete y usa la biblioteca internamente para ofrecer una capacidad a personas usuarias finales.

Aquí conviven tres niveles distintos: la biblioteca define el contrato programático, el paquete define la forma de distribución y la aplicación define la experiencia de uso final. Distinguirlos evita mezclar decisiones de API, distribución y uso final, aunque en la práctica formen parte del mismo proyecto.

Gradle como herramienta, build.gradle.kts como script y plugin como extensión

En un proyecto Kotlin/JVM, Gradle funciona como herramienta de automatización: se opera con comandos y coordina tareas de compilación, pruebas y publicación.

Dentro de esa herramienta, build.gradle.kts actúa como script: expresa reglas y automatizaciones del proyecto con alcance local 1 , aunque pueda evolucionar hacia convenciones más compartidas.

Cuando un plugin se publica en el Gradle Plugin Portal, sigue siendo un plugin; lo que cambia es su distribución como paquete. Del mismo modo, una biblioteca publicada en Maven Central sigue siendo una biblioteca, aunque Gradle la descargue e integre en el build.

Criterio práctico para este curso

A partir de aquí conviene usar una pregunta simple como filtro de diseño: ¿qué artefacto estamos construyendo y para quién? Esa pregunta ordena mejor las decisiones que vendrán en el curso.

  • Si estamos diseñando una biblioteca, el foco debe ir hacia API, claridad, composición y estabilidad para otras personas desarrolladoras.
  • Si estamos resolviendo una automatización local, probablemente hablamos primero de un script y recién después evaluamos si necesita crecer hacia herramienta.
  • Si discutimos publicación, registros o instalación, muchas veces el concepto clave ya no es el tipo de lógica, sino el paquete como unidad de distribución.
  • Si pensamos build y automatización, importa mucho saber cuál de estos artefactos se intenta sostener, porque no todos requieren el mismo tipo de proceso ni el mismo nivel de contrato.

Conclusiones

Biblioteca, aplicación, script, herramienta, plugin y paquete no nombran lo mismo. Cada término destaca una forma distinta de consumo, extensión o distribución, y con ella expectativas diferentes sobre interfaz, estabilidad, documentación y mantenimiento.

Fijar esta distinción al comienzo del curso evita mezclar planos que conviene separar. No es lo mismo diseñar una API para integración, automatizar una tarea local, extender una herramienta existente o publicar algo para que circule en un ecosistema. Aunque esos artefactos puedan compartir código, no prometen lo mismo hacia afuera.

Con ese mapa instalado, la siguiente pregunta ya no es genérica, sino precisa: qué vuelve particular a la biblioteca dentro de esta taxonomía y por qué su diseño se evalúa sobre todo por la claridad, composición y estabilidad de la API que ofrece a otras personas desarrolladoras.

Puntos clave

  • Una biblioteca se diseña para integración programática; una aplicación, para uso final directo.
  • Un script suele resolver una automatización local o acotada; una herramienta ya exige una interfaz de uso más estable para otras personas o equipos.
  • Un plugin no se define por distribución, sino por extender un artefacto anfitrión mediante puntos de extensión predefinidos.
  • Un paquete es, ante todo, una unidad de distribución y puede transportar distintos tipos de artefacto.
  • La pregunta qué artefacto estamos diseñando y para quién organiza mejor las decisiones de API, automatización, distribución y build.

¿Qué nos llevamos?

La taxonomía no es un desvío antes del contenido «real» del curso, sino la base que permite discutirlo con precisión. Una vez distinguido el mapa general de artefactos, podemos entrar en la biblioteca como un caso particular y evaluar su diseño con un criterio mucho más claro.

Notas

  1. Al proyecto. Volver

¿Con ganas de más?