Distingue capacidades diferenciadoras, de soporte y genéricas para orientar la inversión técnica. Analiza una tienda con recomendaciones personalizadas, modela una regla breve en TypeScript y compara decisiones de construir, comprar y aprender.
Una tienda especializada promete ayudar a elegir equipos compatibles con las necesidades de cada comprador. Sus clientes no buscan solamente un catálogo: quieren evitar combinaciones que no funcionan y entender por qué una alternativa les conviene.
El equipo dedica semanas a personalizar pantallas de acceso, construir un sistema propio de notificaciones y reorganizar una aplicación administrativa. Mientras tanto, el recomendador sigue ordenando por popularidad y sugiere productos incompatibles.
Todas esas piezas pueden ser necesarias. La pregunta estratégica es otra: ¿dónde debe concentrarse el conocimiento y el esfuerzo que hacen diferente a este negocio?
Core Domain, o dominio principal, ayuda a responderla. No es un patrón que se implemente creando una carpeta core. Es una forma de reconocer qué parte del dominio merece atención especial porque sostiene la propuesta diferenciadora.
El Core Domain concentra el conocimiento y las capacidades del dominio que resultan centrales para la estrategia y la diferenciación de una organización.
Evans propone distinguir esa parte del resto del modelo, mantenerla enfocada e invertir en comprenderla y desarrollarla con especial cuidado. También advierte que la infraestructura y los problemas más cómodos de definir pueden absorber el esfuerzo mientras el conocimiento especializado queda relegado. DDD Reference: Core Domain, página 40 del documento.
No se trata de declarar superior a un equipo. Se trata de decidir dónde una mejora propia puede producir una ventaja relevante para la estrategia.
En la tienda del ejemplo, la hipótesis es:
Entender necesidades técnicas y recomendar combinaciones adecuadas permite a los clientes elegir mejor que con un catálogo genérico.
Todavía es una hipótesis de diferenciación. Necesitamos contrastarla con clientes, especialistas y resultados; poner «motor inteligente» en una presentación no la demuestra.
La capacidad puede combinar conocimiento, datos, reglas y experiencia de una forma especialmente útil para un segmento.
Un algoritmo publicado puede formar parte de la solución. La diferencia puede estar en reconocer restricciones que otros ignoran, evaluar resultados o incorporar aprendizaje especializado.
Por eso «lo desarrollamos nosotros» y «es secreto» no son criterios suficientes. Un sistema propio de recuperación de contraseñas puede ser costoso y confidencial sin convertirse en una ventaja competitiva.
Para priorizar, conviene distinguir el dominio principal de capacidades de soporte y genéricas.
Core Domain: contribuye directamente a la diferenciación buscada. Merece profundizar en el modelo y conservar capacidad de decisión sobre su evolución.
Supporting Subdomain: resuelve necesidades particulares que permiten operar, pero no constituye por sí mismo la razón diferenciadora por la que el cliente elige la propuesta.
Generic Subdomain: aborda un problema ampliamente conocido, para el que existen enfoques y alternativas reutilizables. Ser genérico no significa ser sencillo ni poco importante.
Esta clasificación no ordena a las personas por valor ni asigna automáticamente presupuestos. Describe el papel de una capacidad frente a una estrategia.
En nuestra tienda suponemos que la operación de pedidos necesita algunos ajustes propios, pero no es la ventaja buscada. La clasificamos provisionalmente como soporte. La autenticación convencional es genérica en este alcance.
Si la empresa se especializara en identidades digitales o en una logística extraordinaria, la clasificación podría cambiar.
Sin autenticación segura o pagos confiables, la tienda puede perder clientes y detener su operación. Eso no implica que deba construir tecnología de identidad o procesamiento financiero desde cero.
Hay dos preguntas diferentes:
Una capacidad genérica crítica necesita calidad, controles y continuidad suficientes. El Core Domain no justifica descuidar seguridad, accesibilidad, cumplimiento o corrección del resto del producto.
La clasificación ayuda a elegir cómo cubrir esas necesidades y dónde invertir esfuerzo de diseño propio, sin retirar las garantías básicas.
Un subdominio describe una parte del problema del negocio. Un Bounded Context delimita dónde se aplica un modelo concreto para resolverlo.
Identificar «selección técnica personalizada» como dominio principal no establece automáticamente que deba existir un único contexto llamado Recommendations.
Podría representarse mediante modelos separados de necesidades, compatibilidad y recomendación. O una primera aplicación podría resolverlo con un modelo pequeño.
Estrategia de la tienda
Ayudar a elegir equipos adecuados
|
v
Capacidad candidata a Core Domain
Selección técnica personalizada
|
v
Diseño de modelos y límites
Una o varias decisiones de Bounded Context
|
v
Implementación y operación
Módulos, código, datos y herramientas
El diagrama muestra decisiones relacionadas, no una regla de correspondencia uno a uno.
Un módulo técnico, la base de datos central o la aplicación con más usuarios tampoco se convierten en Core Domain por su ubicación o tamaño.
En vez de clasificar carpetas, escribimos capacidades observables:
Después discutimos cada capacidad con personas de negocio, producto y tecnología. Una matriz cualitativa inicial puede verse así:
Capacidad Diferenciación prevista Clasificación provisional
Selección personalizada Alta, por validar Core Domain
Gestión operativa pedidos Baja en esta estrategia Supporting
Autenticación habitual No buscada aquí Generic
Avisos operativos No buscada aquí Generic
No es una medición ni un resultado de investigación. Es una propuesta para hacer visibles los supuestos de la tienda ficticia.
¿Por qué nos elegiría el cliente? Si la respuesta es asesoramiento adecuado, identifica qué decisiones lo producen. «Tener un recomendador» es demasiado amplio.
¿Qué conocimiento especializado requiere? Busca reglas que los especialistas pueden explicar con casos, restricciones y excepciones.
¿Qué alternativas existen? No presupongas que comprar es suficiente ni que no hay soluciones adecuadas. Una decisión real necesita investigación de mercado y pruebas con necesidades propias.
¿Qué aprendizaje necesitamos controlar? Si cada experimento depende de que un tercero cambie sus prioridades, quizá estemos limitando la evolución de una capacidad estratégica.
¿Qué evidencia contradice la hipótesis? Si los clientes valoran principalmente entrega inmediata, la recomendación podría no ser la capacidad que más conviene priorizar.
Una clasificación útil admite preguntas pendientes. Una etiqueta elegida por entusiasmo técnico puede ocultarlas.
El equipo propone un motor inteligente de recomendaciones. Antes de entrenar o integrar un modelo, los especialistas identifican una regla:
Un producto incompatible con una necesidad obligatoria no debe recomendarse, aunque sea popular o rentable. Entre alternativas compatibles y dentro del presupuesto, nuestra propuesta prioriza la reparabilidad.
La regla expresa una decisión del negocio. Hay que validarla con clientes y con la estrategia; no es una receta universal para recomendar.
Podemos empezar con una política determinista que haga visible esa decisión. No implementa aprendizaje automático ni demuestra personalización inteligente completa.
El archivo propuesto recommendation-policy.ts no usa paquetes externos y puede formar parte de una aplicación Node.js.
export interface BuyerNeeds {
readonly requiredCapabilities: readonly string[];
readonly budgetCents: number;
}
export interface CandidateProduct {
readonly productId: string;
readonly capabilities: readonly string[];
readonly priceCents: number;
readonly repairable: boolean;
}
export function recommendSuitableProducts(
needs: BuyerNeeds,
candidates: readonly CandidateProduct[],
): CandidateProduct[] {
if (!Number.isSafeInteger(needs.budgetCents) || needs.budgetCents < 0) {
throw new Error("Presupuesto inválido");
}
return candidates
.filter(product => {
const validPrice =
Number.isSafeInteger(product.priceCents) &&
product.priceCents >= 0;
return validPrice &&
product.priceCents <= needs.budgetCents &&
needs.requiredCapabilities.every(
capability => product.capabilities.includes(capability),
);
})
.sort((first, second) =>
Number(second.repairable) - Number(first.repairable) ||
first.priceCents - second.priceCents ||
(first.productId < second.productId ? -1 :
first.productId > second.productId ? 1 : 0),
);
}
La función filtra restricciones obligatorias antes de ordenar. La reparabilidad tiene prioridad entre productos elegibles; después se usa precio y una referencia estable para resolver empates.
Los importes del ejemplo están en céntimos de EUR. Se asumen identificadores únicos, capacidades normalizadas y datos de catálogo validados antes de llegar a la función. No se infiere compatibilidad por similitud de texto.
Un producto de precio inválido se excluye. Si no hay candidatos adecuados, el resultado es vacío: no relajamos silenciosamente una necesidad obligatoria para rellenar la lista.
Una solución real requiere representar mejor capacidades y compatibilidades, explicar decisiones, considerar vigencia de datos y establecer el proceso de evaluación. La función solo muestra una regla que merece nombre, discusión y pruebas.
Una prueba propuesta puede proteger la exclusión de un producto incompatible aunque sea reparable. Presupone compilación de TypeScript a JavaScript ESM y usa APIs integradas de Node.js; no se ha ejecutado como parte del artículo.
import test from "node:test";
import assert from "node:assert/strict";
import { recommendSuitableProducts } from "./recommendation-policy.js";
test("la reparabilidad no compensa una capacidad obligatoria ausente", () => {
const result = recommendSuitableProducts({
requiredCapabilities: ["usb-c-power"],
budgetCents: 20_000,
}, [
{
productId: "repairable-but-incompatible",
capabilities: ["usb-a"],
priceCents: 5_000,
repairable: true,
},
{
productId: "compatible",
capabilities: ["usb-c-power"],
priceCents: 8_000,
repairable: false,
},
]);
assert.deepEqual(
result.map(product => product.productId),
["compatible"],
);
});
La prueba verifica una regla del modelo. No demuestra que el producto sea realmente compatible en el mundo físico ni que recomendarlo mejore las ventas.
Esas afirmaciones requieren datos confiables y evaluación del resultado. La diferencia entre corrección del cálculo y valor para el cliente debe permanecer visible.
Para la tienda, un primer experimento podría comparar la política propuesta con su selección actual en un conjunto de casos revisados por especialistas.
La evaluación debería preguntar:
Son preguntas de evaluación, no métricas ya medidas. No podemos afirmar mejoras sin observarlas.
Si la política no ofrece una ventaja suficiente, el siguiente paso puede ser revisar la hipótesis o usar una alternativa disponible, en vez de añadir complejidad al algoritmo.
El Core Domain orienta dónde aprender con más cuidado. No convierte cualquier inversión en esa zona en una buena decisión.
Clasificar una capacidad ayuda a formular la decisión, pero no produce una orden rígida.
Para una autenticación convencional, conviene evaluar soluciones existentes antes de invertir en una implementación propia. La elección debe considerar requisitos, operación, integración, coste total y posibilidad de salida.
Para una operación de pedidos específica, puede ser adecuado adaptar una solución o implementar partes acotadas si las alternativas no cubren las reglas necesarias.
Para recomendaciones estratégicas, interesa conservar control sobre las decisiones y el aprendizaje que diferencian la propuesta. Eso no obliga a construir modelos de IA, motores de búsqueda o almacenamiento desde cero.
La tienda podría utilizar tecnología externa para generar candidatos y mantener sus reglas de compatibilidad y evaluación. Comprar herramientas no equivale necesariamente a entregar todo el conocimiento estratégico.
A la inversa, un recomendador propio que solo replica popularidad estándar puede aportar poca diferenciación aunque esté desarrollado internamente.
Invertir en el Core Domain puede significar:
No implica añadir todos los patrones tácticos de DDD ni construir una arquitectura distribuida. Si una función explícita y bien probada representa la regla actual, puede ser suficiente.
Las capacidades genéricas y de soporte siguen necesitando responsables y mantenimiento. Relegarlas sin cuidado puede convertirlas en el cuello de botella que impide aprovechar la diferenciación.
La decisión de inversión debe considerar también riesgo y urgencia. Una vulnerabilidad crítica en una capacidad genérica puede tener prioridad inmediata sobre una mejora del recomendador.
Imagina que la tienda deja de competir por asesoramiento y pasa a especializarse en entregar repuestos en pocas horas.
La selección personalizada puede seguir siendo útil, pero la asignación de existencias, preparación y promesa de entrega podría convertirse en el foco diferenciador.
Eso no significa que el código cambie de clasificación cada semana. Significa que una decisión estratégica importante exige revisar dónde se concentra el esfuerzo.
Una ficha breve puede registrar:
Capacidad: selección técnica personalizada.
Clasificación actual: candidata a Core Domain.
Hipótesis: los clientes valoran compatibilidad y explicación por encima de una lista popular.
Conocimiento: necesidades, restricciones, relaciones entre productos y criterios de adecuación.
Evidencia pendiente: revisión de casos y evaluación con usuarios.
Decisión inicial: modelar y evaluar una política pequeña antes de ampliar automatización.
Revisión: cambios de estrategia o evidencia que contradiga la hipótesis.
No hace falta inventar una cifra de retorno para justificar que existe incertidumbre. Hay que decidir cómo reducirla.
Supongamos una plataforma que se diferencia por ayudar a identificar lagunas de comprensión y proponer práctica adecuada.
Su dominio principal candidato puede estar en diagnóstico, secuenciación y retroalimentación pedagógica. La biblioteca de contenidos, el calendario de publicación y el acceso de usuarios pueden desempeñar otros papeles.
Un simple recomendador de cursos populares no expresa necesariamente esa diferenciación. El conocimiento valioso podría estar en reconocer errores conceptuales y elegir una actividad que permita superarlos.
En otra plataforma cuyo negocio consiste en distribuir contenido de terceros a gran escala, la eficiencia de distribución o las condiciones de acceso podrían tener más peso estratégico.
No clasifiques «educación», «pagos» o «recomendaciones» de forma universal. Especifica organización, segmento, propuesta y necesidad.
Este ejemplo también recuerda que el Core Domain puede depender de conocimientos que no están inicialmente en el código. Conversar con docentes y observar aprendizaje puede ser más útil que comenzar con infraestructura.
En la tienda, autenticación convencional era genérica. En una organización que compite por ofrecer una verificación de identidad particularmente adecuada para cierto mercado, parte del análisis de riesgo o de la comprobación podría ser estratégica.
Eso no convierte toda su infraestructura de login en dominio principal ni significa inventar primitivas criptográficas.
La clasificación debe ser lo suficientemente precisa para separar el conocimiento diferenciador de mecanismos que pueden resolverse con estándares y herramientas existentes.
El aprendizaje es doble: la criticidad no basta para clasificar y el nombre técnico de una capacidad tampoco fija su papel.
Llamar core a todo lo importante. Si todas las capacidades reciben la etiqueta, no ayuda a priorizar.
Confundir complejidad con diferenciación. Un sistema difícil puede ser genérico; una regla breve puede expresar conocimiento valioso.
Confundir una demo de IA con ventaja competitiva. Un modelo sofisticado necesita una necesidad real, datos adecuados y evaluación. La novedad técnica no sustituye esos elementos.
Invertir solo en infraestructura porque es más fácil de medir. Puede ser necesaria, pero debe conectarse con riesgos o resultados concretos, no absorber por defecto el trabajo estratégico.
Convertir la clasificación en una jerarquía permanente de equipos. Las capacidades cambian y las personas necesitan colaboración y aprendizaje. La etiqueta no justifica aislar conocimiento o descuidar otras áreas.
Suponer que comprar elimina responsabilidad. La organización sigue respondiendo por la integración, el uso de los datos y la calidad de su propuesta.
Cursor, Claude o Codex pueden ayudar a estructurar capacidades y explorar alternativas, siempre que reciban el contexto del negocio.
Para clasificar provisionalmente:
Analiza estas capacidades y esta propuesta de valor. Propón candidatas a Core Domain, soporte y genéricas. Para cada una, distingue evidencia, hipótesis y preguntas pendientes. No clasifiques por complejidad técnica ni asumas que usar IA es diferenciador.
Para evaluar construir o comprar:
Compara mantener control de esta política de recomendación con utilizar una solución externa. Identifica decisiones de negocio que necesitamos poder cambiar, requisitos de datos, costes de integración y condiciones de salida. No inventes proveedores, precios o capacidades; señala qué requiere investigación actual.
Para implementar un experimento:
Implementa una política pequeña que descarte incompatibilidades antes de priorizar alternativas. Incluye pruebas de restricciones y casos sin resultado. No añadas aprendizaje automático ni servicios nuevos sin una necesidad justificada. Explica qué hipótesis del negocio no demuestra el código.
La persona responsable debe validar la estrategia y las prioridades con evidencia. Una lista convincente de capacidades generada por IA no es un estudio de clientes.
Tampoco hay que enviar información sensible del negocio o de usuarios a herramientas externas sin los permisos y controles correspondientes.
La autenticación es el código más complejo de la tienda. El recomendador consta de pocas funciones, pero contiene reglas especializadas que los compradores valoran. ¿Qué dato determina por sí solo cuál es Core Domain?
Una herramienta externa cubre la generación inicial de candidatos, pero no sabe excluir incompatibilidades propias del mercado de la tienda. ¿Utilizarla obliga a abandonar el dominio principal?
La plataforma educativa deja de diferenciarse por práctica adaptativa y empieza a competir por formación certificada para empresas. ¿Qué debe revisarse?
1. Ninguno de los datos técnicos por sí solo. Hay que contrastar la propuesta estratégica y la evidencia de diferenciación. Complejidad y tamaño no sustituyen esa evaluación.
2. No necesariamente. Se puede utilizar tecnología externa y conservar el modelo, las reglas y la evaluación que expresan el conocimiento especializado. La decisión debe comprobar si esa separación permite aprender y evolucionar sin perder control relevante.
3. Las capacidades que sostienen la nueva propuesta y la distribución de inversión. Diagnóstico adaptativo puede cambiar de papel, mientras otras capacidades adquieren relevancia. No basta con renombrar módulos.
Core Domain ayuda a distinguir qué conocimiento merece convertirse en una capacidad especialmente cuidada del software.
Comprueba que puedes explicar qué diferencia al negocio, qué evidencia lo sostiene y qué decisiones necesitas controlar para mejorarlo. Después diseña modelos e inversiones proporcionales a esa necesidad.
Crear una carpeta llamada core es sencillo. Identificar dónde aprender y desarrollar una ventaja útil requiere una conversación continua entre negocio, producto y tecnología.
Cargando tus opciones de aprendizaje…
Cargando conversación…
Integra la colección construyendo una API de pedidos con TypeScript, Express, Zod y SQLite. Incluye los archivos del proyecto, reglas del dominio, eventos, control de versiones, pruebas con Vitest y comandos para ejecutarla y verificarla localmente.
Aprende a orientar agentes de IA con reglas del negocio, límites de contexto y criterios verificables. Un caso en TypeScript muestra cómo preparar instrucciones, proteger Order, diseñar pruebas y revisar cambios sin delegar el criterio arquitectónico.
Compara un monolito modular con una separación de Sales, Payments e Inventory. Diseña contratos en TypeScript y Express y comprende fallos parciales, consistencia eventual, idempotencia, Outbox y Sagas sin introducir infraestructura compleja.