Patrones de arquitectura

Obtenga más información acerca de la optimización de recursos y costes bien arquitectada → Sus responsabilidades de optimización

Esta página proporciona directrices de patrón integrales para problemas arquitectónicos incluyendo unidades funcionales, separación de problemas, gestión de estado, gestión de API y mensajería. Estos patrones dan forma al éxito de la solución a largo plazo a través de decisiones de diseño deliberadas sobre límites de servicio, patrones de acceso a datos y responsabilidades de componentes.

Patrones

Dónde buscar	Qué buen aspecto tiene
Clases Apex	✅ Las clases de servicio siguen el principio de responsabilidad única con nombres que indican claramente el propósito (AccountService, OrderProcessor, InventoryManager). Cada clase de servicio se centra en un dominio o capacidad comercial. Los métodos en clases de servicio tienen responsabilidades únicas y centradas bajo 20 líneas.
Desencadenadores	✅ Desencadena la delegación a clases de gestor en vez de contener lógica comercial directamente. Patrón de controlador de desencadenador utilizado de forma coherente con nombres de método claros por contexto (handleBeforeInsert, handleAfterUpdate). Las clases de controlador organizan la lógica por evento de desencadenador con responsabilidades únicas por método.
Componentes web Lightning	✅ Los componentes siguen el principio de responsabilidad única con interfaces de apoyo claras para la configuración. Cada LWC se centra en una preocupación de la interfaz de usuario (visualización de datos, entrada de usuario, navegación). Componentes diseñados para la composición, no implementaciones monolíticas.
Capa de servicio	✅ Las clases de servicio encapsulan lógica comercial independiente del punto de entrada (desencadenador, API, Flujo, lote). La misma clase de servicio gestiona múltiples contextos de invocación sin duplicación. La capa de servicio separa las reglas comerciales de los problemas de presentación y acceso a los datos.
Componentes reutilizables	✅ Componentes diseñados para su reutilización entre múltiples proyectos y equipos. El comportamiento dirigido por la configuración utilizando tipos de metadatos personalizados activa cambios de comportamiento sin implementación de código. Las acciones invocables exponen la lógica Apex como elementos constructivos declarativos utilizables desde Flujo y orquestación externa.

Antipatrones

Dónde buscar	Aspecto negativo
Clase de Dios	⚠️ Evite acumular excesiva responsabilidad en una sola clase. Divida clases grandes (>500 líneas) en clases centradas con responsabilidades únicas. Reorganice las clases cuando gestionan múltiples problemas no relacionados (OrderProcessor no debería también gestionar el envío de correos electrónicos y la creación de informes).
Problemas mixtos	⚠️ Evite mezclar lógica de desencadenador, reglas comerciales y acceso a datos en clases individuales. Separe la lógica de presentación de la lógica comercial en controladores. Mantenga las preocupaciones de integración separadas de la lógica de dominio principal.
Lógica de desencadenamiento en desencadenadores	⚠️ Evite incrustar lógica comercial directamente en archivos de desencadenador. Nunca utilice más de 300 desencadenadores de línea con condicionales anidados. Delegue siempre en clases de gestor con una organización de método clara por contexto de desencadenador.

Patrones

Dónde buscar	Qué buen aspecto tiene
Lógica comercial	✅ Reglas comerciales centralizadas en clases de servicio, no dispersas entre desencadenadores, controladores y clases por lotes. Las clases de dominio encapsulan el comportamiento a nivel de registro (validación, valores predeterminados, valores derivados) de forma coherente independientemente de cómo entran los registros en el sistema. Lógica reutilizada a través de la capa de servicio en vez de duplicada entre puntos de entrada.
Acceso a datos	✅ Acceso a datos abstraído detrás de clases de patrón de repositorio o selector. Consultas SOQL centralizadas en clases de selector (AccountSelector, OpportunitySelector) garantizando listas de campos coherentes y cláusulas WHERE. El patrón de repositorio permite realizar pruebas con fuentes de datos simuladas sin cambiar la lógica comercial.
Contratos de interfaz	✅ Los componentes se comunican a través de interfaces explícitas en vez de detalles de implementación. Las interfaces Apex definen contratos entre capas. La configuración de metadatos personalizados define límites de comportamiento. Eventos de plataforma proporciona contratos de mensajería entre productores y consumidores.
Límites de módulos	✅ Los contextos acotados definen límites de propiedad claros para modelos de datos y reglas comerciales. Cada módulo posee sus datos, automatización y lógica comercial. Los módulos interactúan a través de API definidas en vez de compartir objetos de base de datos directamente. La documentación identifica claramente qué equipo posee qué objetos y servicios.
Flujo de dependencia	✅ Las dependencias fluyen en una dirección (presentación → negocio → datos). La lógica comercial principal no depende de nada externo, lo que permite una evolución independiente. Los problemas de infraestructura (registro, almacenamiento en caché, API externas) dependen de la lógica comercial a través de interfaces, no viceversa.

Antipatrones

Dónde buscar	Aspecto negativo
Duplicación de lógica	⚠️ Evite duplicar la lógica comercial entre desencadenadores, extremos de API y clases por lotes. Centralice en la capa de servicio y reutilice entre puntos de entrada. Cada vez que aparezca la misma regla comercial en múltiples clases, extraiga al servicio compartido.
Acceso a datos disperso	⚠️ Evite consultas SOQL dispersas entre desencadenadores, controladores y clases por lotes con listas de campos incoherentes y cláusulas WHERE. Centralice consultas en clases de selector garantizando patrones coherentes y activando la optimización de LDV en una sola ubicación.
Lógica comercial en desencadenadores	⚠️ Evite reglas de validación, cálculos de campo y orquestación de flujos de trabajo integrados directamente en código de desencadenador. Pasar a clases de servicio o clases de dominio. Mantenga los desencadenadores delgados, centrados solo en delegar en controladores apropiados.
Lógica comercial en controladores	⚠️ Evite cálculos complejos, validación o manipulación de datos en métodos de controlador Aura/LWC. Los controladores deben orquestar llamadas a la capa de servicio, no implementar reglas comerciales directamente.
Dependencias circulares	⚠️ Evite paquetes o clases con dependencias circulares donde A depende de B y B depende de A. Resuelva extrayendo preocupaciones compartidas en módulos separados, invirtiendo la dirección de dependencia o utilizando comunicación dirigida por eventos para interrumpir el acoplamiento.

Patrones

Dónde buscar	Qué buen aspecto tiene
Caché de plataforma (Partición de organización)	✅ Datos de referencia a los que se accede frecuentemente en caché en la partición de la organización, incluyendo búsquedas de metadatos personalizados, valores de lista de selección, parámetros de configuración y resultados calculados de operaciones costosas. TTL predeterminado configurado basándose en la volatilidad de los datos (horas para datos de referencia que cambian mensualmente, minutos para configuración actualizada frecuentemente). La estrategia de claves de caché evita colisiones entre diferentes tipos de datos.
Caché de plataforma (Partición de sesión)	✅ Preferencias específicas del usuario, datos de personalización calculados y estado con ámbito de sesión almacenado en caché de sesión. Caché de sesión no utilizado para datos que se deben compartir entre usuarios. La estrategia de invalidación de caché gestiona las actualizaciones de preferencias de usuario de forma apropiada.
Servicio de datos Lightning	✅ LDS proporciona almacenamiento en caché de registros del lado del cliente automático para componentes web Lightning. Las operaciones CRUD estándar utilizan LDS en vez de controladores Apex personalizados. LDS elimina los recorridos de ida y vuelta redundantes del servidor y proporciona actualizaciones optimistas de la interfaz de usuario. Los componentes aprovechan la caché LDS compartida entre páginas.
Tipos de metadatos personalizados	✅ Reglas de comportamiento y configuración almacenadas en tipos de metadatos personalizados en vez de codificadas en clases. Metadatos personalizados implementables en entornos a través de conjuntos de cambios o desarrollo dirigido por origen. Los cambios en metadatos personalizados no requieren un ciclo de implementación completo. Almacena en caché consultas de metadatos personalizados en Caché de plataforma para el rendimiento.

Antipatrones

Dónde buscar	Aspecto negativo
Consulta en bucle	⚠️ Evite ejecutar SOQL dentro de bucles de iteración. Consulte todos los registros necesarios en una única instrucción SOQL fuera de los bucles. Organice los resultados en Maps por Id. principal para buscar durante la iteración. Este es el antipatrón más común de Salesforce.
Consultas repetitivas	⚠️ Evite consultar los mismos metadatos personalizados, configuración personalizada o datos de referencia varias veces por transacción. Consulte una vez, almacene en caché en Caché de plataforma o variable estática de transacción, reutilice en transacción.
Estrategia de caché que falta	⚠️ Evite consultar repetidamente datos de referencia a los que se accede con frecuencia sin almacenamiento en caché. Implemente Caché de plataforma para metadatos personalizados, configuración y resultados calculados. Defina el TTL apropiado basándose en la volatilidad de los datos.
Caché sin invalidación	⚠️ Evite el almacenamiento en caché de datos sin considerar la estrategia de invalidación. Defina el TTL de caché apropiado para actualizar la frecuencia. Implemente el borrado manual de caché cuando cambien los datos de origen si TTL solo es insuficiente.
Estado de sesión no gestionado	⚠️ Evite asumir que el estado de la sesión persiste entre las navegaciones de página sin verificación. Los componentes Lightning deben gestionar la actualización de estado en la carga de página. Utilice Lightning Data Service para la sincronización de estado automática.

Patrones

Dónde buscar	Qué buen aspecto tiene
Planificación de arquitectura de soluciones	✅ La planificación de la arquitectura se produce antes de una inversión de construcción significativa, incluyendo el análisis de requisitos (funcional y no funcional), el análisis de límite regulador para volúmenes de datos esperados, la selección de patrones apropiada para requisitos y el diseño de componentes que define componentes e interfaces principales.
Selección de patrón de diseño	✅ Patrones de diseño probados de Salesforce aplicados de forma coherente: Patrón de capa de servicio para reutilización de lógica comercial, Patrón de repositorio/selector para abstracción de acceso a datos, Patrón de estrategia para algoritmos intercambiables, Patrón de dominio para comportamiento a nivel de registro, Patrón de controlador de desencadenador para organización de desencadenador coherente.
Registros de decisiones de arquitectura	✅ Decisiones arquitectónicas significativas documentadas en ADR almacenados en control de versión. Los ADR capturan el contexto (impulsores comerciales, restricciones técnicas), la decisión (lo que se eligió), las alternativas consideradas (por qué se rechazaron otras) y las consecuencias (compensaciones, deuda técnica, desencadenadores de revisitas).
Evaluación Construir frente a Comprar	✅ La evaluación AppExchange precede a las decisiones de desarrollo personalizadas utilizando el análisis de coste total de propiedad. Los criterios de evaluación incluyen el valor estratégico (diferenciador competitivo frente a mercancía), la comparación de TCO (esfuerzo de construcción, mantenimiento, costes de actualización), la complejidad de la integración y el coste de salida si la solución resulta inadecuada.
Análisis de límite regulador	✅ La planificación arquitectónica identifica qué regulador limita el diseño de restricciones en función de los volúmenes de datos y patrones de transacciones previstos. Transacciones diseñadas para consumir menos del 80% de cualquier límite regulador único en condiciones de pico. Margen creado para el crecimiento, funciones futuras y patrones de uso inesperados.
Evaluación de riesgos	✅ Riesgos técnicos identificados para enfoques arquitectónicos que amplían los límites de la plataforma. Estrategias de mitigación definidas para cada riesgo significativo. El trabajo de prototipo o prueba de concepto valida presunciones para enfoques técnicos de alto riesgo antes del compromiso de creación completo.

Antipatrones

Dónde buscar	Aspecto negativo
Sin planificación	⚠️ Evite comenzar la creación sin analizar volúmenes de datos, implicaciones de límite regulador o selección de patrón. El taller de planificación de arquitectura debe identificar restricciones clave, seleccionar patrones y validar con límites reguladores antes de que comience la construcción.
Decisiones indocumentadas	⚠️ Evite decisiones arquitectónicas tomadas en reuniones sin capturar contexto, justificación, alternativas y consecuencias. Utilice Architecture Decision Records (Registros de decisiones de arquitectura) almacenados en el control de versiones preservando el contexto de decisiones para futuros miembros del equipo.
Análisis de No construir frente a comprar	⚠️ Evite crear soluciones personalizadas sin evaluación AppExchange. Evalúe los 3-5 paquetes relevantes principales antes del desarrollo personalizado. Compare el TCO incluyendo el esfuerzo de implementación, el mantenimiento, los costes de actualización y los costes de salida.
Subingeniería	⚠️ Evite diseñar solo para volúmenes de datos actuales sin proyección de crecimiento. Crecimiento de datos de proyecto durante 2-3 años. Diseñe patrones de consulta con selectividad validada frente a 5-10 volúmenes actuales. Cree margen arquitectónico para el crecimiento.

Patrones

Dónde buscar	Qué buen aspecto tiene
Paquetes gestionados de segunda generación (2GP)	✅ 2GP utilizado para nuevos paquetes gestionados que requieren aislamiento de espacio de nombres, distribución AppExchange y protección IP. Flujo de trabajo de desarrollo dirigido por origen con desarrollo de aplicaciones modular. Dependencias de paquetes gestionadas de forma explícita. Versiones publicadas con versión semántica.
Paquetes desbloqueados	✅ Paquetes desbloqueados utilizados para aplicaciones empresariales internas que requieren modularidad sin restricciones de espacio de nombres. Implementación independiente de paquetes sin artefactos dependientes de la organización. Dependencias del paquete supervisadas para un pedido de implementación adecuado. Estrategia de versión definida para paquetes internos.
Límites de módulos	✅ Borre los límites de propiedad definidos para cada paquete. Cada paquete posee su modelo de datos, reglas comerciales y automatización. Los paquetes interactúan a través de interfaces definidas en vez de acceso directo a objetos. La documentación identifica la propiedad de paquetes y los contratos entre paquetes.