JavaScript
Explica cómo diseñar módulos con responsabilidades claras, dependencias controladas y APIs públicas pequeñas que reduzcan acoplamiento y cambios accidentales.
Un buen módulo oculta decisiones internas y expone un contrato pequeño, estable y comprensible.
consumidor
↓ API pública
módulo
↓ detalles internos
infraestructuraUn módulo debería agrupar conceptos que cambian por razones relacionadas.
orders/
create-order.js
cancel-order.js
order-errors.jsNo agrupe funciones solo porque son “helpers”. Define qué responsabilidad comparten.
import { database } from "../../infrastructure/db.js";Si cada módulo de dominio importa infraestructura concreta, el cambio se propaga.
Inyección:
export function createOrderService({ repository }) {
return {
create(input) {
return repository.save(createOrder(input));
},
};
}export {
createOrder,
cancelOrder,
OrderError,
};No exportes funciones internas solo para facilitar un test. Prueba comportamiento público o extrae una unidad con responsabilidad propia.
export function requireProduct() {}
export function findProduct() {}Comunican contratos distintos mejor que getData o handleItem.
UI → application → domain
↓
infrastructure adapterLas capas centrales no deberían importar frameworks o detalles externos innecesariamente.
Menos claro:
// analytics.js
window.addEventListener("click", trackClick);Más controlado:
export function startAnalytics(target) {
target.addEventListener("click", trackClick);
return () => {
target.removeEventListener("click", trackClick);
};
}El llamador conoce inicio y cleanup.
Evita leer globals dentro de cada módulo.
export function createClient({ baseUrl, token }) {}La configuración se valida una vez y se pasa explícitamente.
Un index.js puede ofrecer una entrada cómoda.
export { createOrder } from "./create-order.js";
export { OrderError } from "./order-error.js";Úsalo como frontera pública, no como ruta universal entre archivos internos.
Cambiar implementación:
function calculateTax() {}No debería obligar a todos los consumidores a cambiar si el contrato externo permanece.
Cambiar nombre, forma de parámetros, retorno o errores públicos puede ser breaking change.
throw new OrderNotFoundError(orderId);Si los consumidores dependen de esa clase o code, forma parte de la API.
const service = createService({
clock: fakeClock,
repository: fakeRepository,
});Dependencias explícitas permiten pruebas sin mutar globals ni cargar módulos especiales.
utils.js
services.js
helpers.js
common.jsCuando contienen dominios no relacionados, se convierten en puntos de acoplamiento. Divide por responsabilidad y lenguaje del producto.
export function createHttpClient({
baseUrl,
fetchImplementation,
}) {
return {
async get(path, { signal } = {}) {
const response = await fetchImplementation(
new URL(path, baseUrl),
{ signal },
);
if (!response.ok) {
throw new HttpError(response.status);
}
return response.json();
},
};
}La API es pequeña y el detalle de fetch es sustituible.
¿Por qué exportar una función interna solo para probarla puede ser mala señal?
Porque amplía la API pública por una necesidad interna. Puede indicar que la unidad tiene otra responsabilidad que debería extraerse o que la prueba debería observar el comportamiento público.
Strings, Unicode y template literals inicia el bloque de objetos nativos y formatos.