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:
8 de abril de 2026

Cambios recientes:

  • 217ece5 · 8 de abril de 2026 · 📝🧪 chore(notes): refine artifacts taxonomy and harden webpage references ( GitLab / GitHub )
  • a76aa7a · 2 de abril de 2026 · ✨ ♻️ feat(notes): add Node.js scripting lesson and catalog-driven references ( GitLab / GitHub )
  • 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é artefacto estamos construyendo y para quién. Antes de profundizar en la biblioteca, conviene distinguir el mapa más amplio en el que también aparecen aplicaciones, scripts, herramientas, plugins y paquetes.

La meta no es memorizar etiquetas, sino incorporar un criterio práctico para el resto del curso. Al distinguir relación de uso, contrato y distribución, se vuelve más claro qué vuelve particular a la biblioteca y por qué no se diseña igual que otros artefactos.

¿Qué es un artefacto de software?

Antes de distinguir entre biblioteca, aplicación, script, herramienta o paquete, conviene partir por el concepto más amplio que las reúne. Todas esas categorías son tipos de artefacto de software, no etiquetas aisladas.

Un artefacto de software es una unidad de software diseñada para ser creada, distribuida y usada dentro de un ecosistema técnico. No se define solo por su implementación, sino también por su propósito, su forma de uso y el tipo de consumo que habilita para personas, programas u otras herramientas.

Por eso, al diseñar software, no basta con preguntarse cómo construirlo. También hay que preguntarse qué artefacto estamos creando, quién lo va a usar y de qué manera. Esa distinción influye en decisiones de diseño, automatización, publicación y mantenimiento.

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 describe una relación de uso distinta: cambia quién consume el artefacto, cómo lo hace, qué estabilidad espera y qué contrato debe ofrecerse.

Esa diferencia importa porque el diseño no depende solo de la funcionalidad interna, sino también de la forma de uso que se expone 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í ser artefactos distintos. Lo decisivo no es solo la lógica interna, sino cómo se consumen y qué contrato prometen hacia afuera.

Por ejemplo, una misma lógica podría reutilizarse como biblioteca, exponerse como herramienta de línea de comandos o envolverse en un script de automatización. En cada caso cambian las decisiones de distribución, documentación, validación y mantenimiento.

Hacer 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.

Definiciones operativas

En esta lección, la distinción base se organiza alrededor de formas de uso: biblioteca, aplicación, script y herramienta. La diferencia entre aplicación y herramienta es de enfoque: mientras una aplicación prioriza la experiencia de uso final, una herramienta prioriza la operación técnica clara y repetible. 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. Su foco no es la operación directa, sino la reutilización programática. Ejemplos claros son kotlinx.coroutines 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. Su rasgo principal no es el lenguaje en que está escrito, sino el hecho de priorizar rapidez y bajo costo de arranque por sobre un contrato público estable para terceros. build.gradle.kts es un ejemplo típico de script.

Herramienta

Una herramienta es un artefacto pensado para uso técnico directo por parte de otras personas o equipos. Suele ofrecer una interfaz operable y repetible — por ejemplo, una CLI, un linter o un generador — y por eso exige instalación, documentación y comportamiento estable. ktlint y detekt son ejemplos del ecosistema Kotlin.

Plugin

Un plugin extiende el comportamiento de un artefacto anfitrión mediante puntos de extensión definidos por ese anfitrión. Se integra dentro del ciclo de vida de la plataforma que lo carga, no arbitrariamente desde código. Un plugin de Gradle o de IntelliJ IDEA son ejemplos típicos.

Paquete

Un paquete es una unidad de distribución dentro de un ecosistema. No describe primero cómo se usa el software, sino cómo se publica, instala y versiona. Un paquete puede contener una biblioteca, una herramienta, una aplicación o una combinación de ellas. Los artefactos publicados en Maven Central o los crates de Cargo son ejemplos.

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.

Nota

No todos estos ejes tienen igual peso en todas las situaciones; algunos importan más para ciertos artefactos que para otros. 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 acotada, normalmente desde terminal, CI, scheduler o hook; automatización de una tarea concreta en un contexto local o de equipo.
  • 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: entradas conocidas, tarea clara y comportamiento predecible dentro de su contexto acotado.
  • 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.
  • Plugin: media a alta; depende del contrato de extensión definido por el anfitrión y de su ciclo de vida.

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.
  • Plugin: repositorios o portales del ecosistema anfitrión, junto con metadatos que permiten su carga automática o descubrimiento.

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.

Un ejemplo que integra varios ejes: un proyecto Kotlin/JVM puede publicar una biblioteca en Maven Central como paquete (distribución + consumo programático), incluir un plugin de Gradle (extensión + distribución en portal) e incluir una herramienta CLI también empaquetada (operación técnica + binario compartido). Cada uno de estos artefactos ocupa una fila distinta en los ejes, pero conviven en el mismo proyecto porque responden a necesidades diferentes de quien los consume.

Casos comparativos

De script local a herramienta compartida

Imagina un script que renombra archivos para una necesidad puntual 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 un contrato de uso para otras personas.

La situación cambia cuando otras personas del equipo empiezan a depender de esa misma automatización. En ese momento ya no basta con que funcione: hace falta pensar en instalación, mensajes de error, parámetros claros, comportamiento repetible, compatibilidad del entorno y documentación de uso. La lógica puede seguir siendo parecida, 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 necesitar conocer la implementación. A partir de ahí, ya no basta con que la automatización exista: su uso también tiene que ser claro, repetible y predecible.

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

Considera kotlinx.serialization como una biblioteca reutilizable. Su API está pensada para otras personas que desarrollan software, así que importan nombres claros, tipos coherentes y comportamiento estable.

Para circular en el ecosistema, esa biblioteca puede publicarse como paquete en Maven Central. El paquete no reemplaza a la biblioteca ni redefine su propósito: define su forma de distribución dentro del ecosistema, con versión, metadatos y dependencias. Luego, una aplicación — por ejemplo, una app Android en Kotlin — puede declarar esa dependencia y usar la biblioteca internamente para ofrecer una capacidad a sus personas usuarias.

Aquí conviven tres niveles distintos: la biblioteca define el contrato programático, el paquete define la forma de distribución y la aplicación organiza la experiencia de uso final. Distinguirlos evita mezclar decisiones de API, distribución y uso, incluso cuando estos niveles participan en una misma solución.

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

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

Dentro de esa herramienta, build.gradle.kts actúa como script: define reglas de build y automatización para el proyecto o módulo actual, aunque parte de esa lógica pueda migrar después a convenciones más compartidas.

Un plugin, en cambio, es una extensión del anfitrión. En este caso, amplía Gradle a través de puntos de extensión definidos por la propia herramienta. Si ese 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. Este ejemplo muestra que en un mismo ecosistema pueden convivir herramienta, script, plugin y paquete, cada uno con un papel distinto.

Criterio práctico para este curso

Desde aquí conviene usar una pregunta simple como filtro de diseño: ¿qué artefacto estamos construyendo y para quién? Esa pregunta ayuda a ordenar las decisiones que aparecen a lo largo del curso.

  • Si estamos diseñando una biblioteca, el foco debe ponerse en la API, la claridad, la composición y la estabilidad para otras personas desarrolladoras.
  • Si estamos resolviendo una automatización puntual, probablemente partimos con un script y luego evaluamos si debe convertirse en una herramienta compartida.
  • Si discutimos publicación, registros o instalación, muchas veces el concepto clave ya no es la forma de uso, sino el paquete como unidad de distribución.
  • Si pensamos en build y automatización, importa identificar qué artefacto se está sosteniendo, porque no todos exigen el mismo proceso ni el mismo nivel de contrato.

Este criterio no distingue artefactos por tamaño o complejidad, sino por la relación de uso que establecen y por las exigencias de diseño que esa relación trae consigo.

Conclusiones

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

Distinguir estos artefactos desde el comienzo evita mezclar preguntas de diseño que conviene separar. Aunque distintos artefactos puedan compartir código, no establecen el mismo contrato hacia afuera ni se evalúan con los mismos criterios.

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 acotada; una herramienta exige una interfaz de uso más estable para terceros.
  • Un plugin se define por extender a un anfitrión mediante puntos de extensión predefinidos.
  • Un paquete es una unidad de distribución y puede transportar distintos tipos de artefacto.
  • Estas categorías no son excluyentes: un mismo proyecto puede combinar varias.
  • La pregunta qué artefacto estamos diseñando y para quién organiza mejor las decisiones de API, automatización, distribución y build.

Reflexión de cierre

Con este mapa general ya instalado, el curso puede concentrarse en la biblioteca como caso particular. La pregunta que sigue ya no es qué es un artefacto de software en general, sino qué exige diseñar una biblioteca reusable para otras personas desarrolladoras.

¿Con ganas de más?