Patrones de arquitectura

Obtenga más información acerca de Optimización de recursos y costos 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é 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 de negocio. Los métodos en clases de servicio tienen responsabilidades únicas y centradas bajo 20 líneas.
Desencadenadores	✅ Los desencadenadores delegan en clases de gestor en vez de contener lógica de negocio 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 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 de negocio 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 de negocio 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 responsabilidad excesiva 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 debe gestionar también el envío de email y la creación de reportes).
Preocupaciones mixtas	⚠️ Evite mezclar lógica de desencadenador, reglas de negocio y acceso a datos en clases únicas. Separe la lógica de presentación de la lógica de negocio en controladores. Mantenga las preocupaciones de integración separadas de la lógica de dominio principal.
Lógica de desencadenador en desencadenadores	⚠️ Evite incrustar lógica de negocio 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é aspecto tiene
Lógica de negocio	✅ Reglas de negocio 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 orígenes de datos simulados sin cambiar la lógica de negocio.
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 de negocio. Cada módulo posee sus datos, automatización y lógica de negocio. 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 es propietario de qué objetos y servicios.
Flujo de dependencia	✅ Las dependencias fluyen en una dirección (presentación → negocio → datos). La lógica de negocio 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 de negocio a través de interfaces, no viceversa.

Antipatrones

Dónde buscar	Aspecto negativo
Duplicación de lógica	⚠️ Evite duplicar la lógica de negocio entre desencadenadores, extremos de API y clases por lotes. Centralice en la capa de servicio y reutilice entre puntos de entrada. Siempre que aparezca la misma regla de negocio 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 de negocio en desencadenadores	⚠️ Evite reglas de validación, cálculos de campos y orquestación de flujos de trabajo integrados directamente en el código de desencadenador. Pase a clases de servicio o clases de dominio. Mantenga los desencadenadores atenuados, centrados solo en delegar en controladores apropiados.
Lógica de negocio 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 de negocio 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é aspecto tiene
Caché de plataforma (Partición de organización)	✅ Datos de referencia a los que se accede frecuentemente almacenados 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 caché de registros del lado del cliente automático para componentes web Lightning. Las operaciones CRUD estándar utilizan controladores LDS en vez de Apex personalizados. LDS elimina recorridos de ida y vuelta de servidor redundantes y proporciona actualizaciones de interfaz de usuario optimistas. 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 entre entornos a través de conjuntos de cambios o desarrollo dirigido por origen. Los cambios en metadatos personalizados no requieren ciclo de implementación completo. Almacene en caché consultas de metadatos personalizados en Caché de plataforma para el desempeño.

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 sola instrucción SOQL fuera de los bucles. Organice los resultados en Maps por Id. principal para su búsqueda durante la iteración. Este es el antipatrón de Salesforce más común.
Consultas repetitivas	⚠️ Evite consultar los mismos metadatos personalizados, configuraciones personalizadas 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 entre transacciones.
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 almacenar datos en caché sin tener en cuenta la estrategia de invalidación. Defina el TTL de caché apropiado para actualizar la frecuencia. Implemente el borrado de caché manual cuando cambien los datos de origen si el 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 la página. Utilice Lightning Data Service para la sincronización de estado automática.

Patrones

Dónde buscar	Qué 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ímites reguladores para volúmenes de datos esperados, la selección de patrones apropiados 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 de negocio, 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 almacenadas en el control de versiones. Las RAM capturan el contexto (impulsores de negocio, 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).
Crear vs Comprar evaluación	✅ La evaluación AppExchange precede a las decisiones de desarrollo personalizadas utilizando el análisis de costo 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, costos de actualización), la complejidad de la integración y el costo de salida si la solución resulta inadecuada.
Análisis de límites 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 los 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 supuestos para enfoques técnicos de alto riesgo antes del compromiso de construcción completo.

Antipatrones

Dónde buscar	Aspecto negativo
Sin planificación	⚠️ Evite comenzar a crear sin analizar volúmenes de datos, limitar implicaciones o seleccionar patrones. 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 almacenados en el control de versiones conservando el contexto de decisiones para futuros miembros del equipo.
Análisis Sin 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 costos de actualización y los costos 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é 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 de 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 de negocio internas que requieren modularidad sin restricciones de espacio de nombres. Implementación independiente de paquetes sin artefactos dependientes de la organización. Dependencias de paquetes supervisadas para un ordenamiento de implementación adecuado. Estrategia de versionado 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 de negocio 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 del paquete y los contratos entre paquetes.