Doplax.Dev
  • Home
  • About me
  • Blog
  • Work Experience
  • Contact
  • Home
  • About me
  • Blog
  • Work Experience
  • Contact

Got a project in mind or just want to say hi?

Get in touch

© 2026 Doplax.Dev — All rights reserved.

February 4, 2026

Core vs Shared: diferencias clave entre estas carpetas en la arquitectura de un proyecto

  • Productivity

En muchos proyectos aparece una duda recurrente:

¿qué va en core y qué va en shared****?

A simple vista ambas parecen cajones de sastre, y cuando no se definen bien acaban llenas de código que “no sabemos dónde poner”. El resultado suele ser acoplamiento, dependencias circulares y una arquitectura difícil de mantener.

Entender la responsabilidad de cada una es clave para que la estructura del proyecto tenga sentido.

Qué es la carpeta core

La carpeta core contiene el núcleo técnico y funcional de la aplicación. Es código que:

  • Existe una sola vez
  • Es necesario para que la aplicación funcione
  • Orquesta el comportamiento global del sistema

Características:

  • Código singleton o de inicialización
  • Alto nivel de responsabilidad
  • No debería depender de shared
  • Se carga una única vez

Ejemplos típicos de core:

  • Configuración global
  • Gestión de sesión o estado global
  • Guards, middlewares o interceptores
  • Servicios base
  • Inicialización del sistema

Ejemplo conceptual:

export class AuthSession {
  private token: string | null = null;

  setToken(token: string) {
    this.token = token;
  }

  isAuthenticated(): boolean {
    return this.token !== null;
  }
}

🧠 Debug mental

token = 'abc123'
isAuthenticated() // true

Este tipo de código no pertenece a una funcionalidad concreta, sino al funcionamiento general del sistema.

Qué es la carpeta shared

La carpeta shared contiene piezas reutilizables, pequeñas y sin estado global. Son bloques que pueden ser usados en múltiples partes del proyecto sin conocer el contexto completo.

Características:

  • Reutilizables
  • Sin lógica de negocio crítica
  • Bajo acoplamiento
  • No dependen de core

Ejemplos típicos de shared:

  • Utilidades
  • Tipos comunes
  • Validadores simples
  • Componentes genéricos
  • Helpers puros

Ejemplo:

export function isEmail(value: string): boolean {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value);
}

🧠 Debug mental

isEmail('test@mail.com') // true
isEmail('test@')        // false

Este código no sabe nada del sistema, solo cumple una función concreta.

Diferencia clave entre core y shared

La distinción fundamental es esta:

| Core | Shared | | -------------------- | -------------------- | | Código único | Código reutilizable | | Estado global | Sin estado global | | Orquesta el sistema | Piezas aisladas | | Alta responsabilidad | Baja responsabilidad |

Regla mental rápida:

se rompe, ¿se cae toda la aplicación?

Errores comunes

Usar shared como “cajón desastre”

Cuando algo no encaja, se mete en shared. Con el tiempo:

  • Mezcla lógica de negocio
  • Aumenta el acoplamiento
  • Se vuelve intocable

Meter lógica reutilizable en core

Si una utilidad no necesita contexto global, no debería vivir en core.

Esto convierte el núcleo en algo innecesariamente pesado.

Ejemplo de estructura clara

Cada carpeta tiene una responsabilidad clara y limitada.

Cómo decidir dónde va algo

Hazte estas preguntas:

  1. ¿Tiene estado global?
  1. ¿Se inicializa una sola vez?
  1. ¿Es crítico para el funcionamiento del sistema?

Si la respuesta es sí → probablemente core.

Si, en cambio:

  • Es reutilizable
  • Es puro
  • No necesita contexto

→ shared.


core y shared no son lo mismo ni deberían usarse indistintamente.

Uno define el corazón del sistema, el otro proporciona herramientas reutilizables.

Cuando esta diferencia está clara, la arquitectura se vuelve más predecible, el código más fácil de entender y el proyecto mucho más sostenible a largo plazo.

PreviousCrear alias path de nuestras rutas NextData Binding en Angular: qué es, tipos y cómo funciona realmente

Related posts

  • Simplify Your Imports in JavaScript with Module AliasesProductivity

Written by Pol Valle

Written by Pol Valle

I'm particularly drawn to building apps that are not only functional but also visually appealing and easy to use. I do it by applying SOLID principles, clean architecture and testing to ensure quality.