Lea sobre nuestras programaciones de actualización aquí.

Las soluciones componebles se ajustan rápidamente y con mayor estabilidad. Un sistema diseñado para ser componible está construido en unidades significativas, o bloques constructivos, que pueden operar elegantemente entre sí y pueden intercambiarse fácilmente dentro y fuera de servicio. La integración de la compostabilidad en un sistema le permite introducir nuevas funciones o eliminar deudas técnicas refactorizando o volviendo a montar unidades individuales de un sistema. La capacidad de redacción permite versiones y ciclos de entrega más rápidos y predecibles, ya que los equipos pueden centrarse en crear y entregar funciones significativas a través de cantidades más pequeñas de cambios.

Los sistemas con capacidad de composición permiten a las empresas adaptarse con mayor rapidez y estabilidad, ya sea que el estímulo sea interno de la empresa o causado por factores externos. La composibilidad ayuda a los sistemas a ser más resilientes y puede ayudar a hacer que las soluciones y los patrones arquitectónicos sean más intencionados.

Puede hacer que sus soluciones de Salesforce sean más componibles creando tres hábitos clave: separación de preocupaciones, interoperabilidad y empaquetabilidad. A continuación, puede ver la relación de estos hábitos de dos formas: para una única unidad en un sistema componible y entre múltiples unidades en un sistema componible.

Una única unidad componible:

Un sistema componible:

Concepto fundamental en la ingeniería de software y la arquitectura de sistemas, la separación de preocupaciones implica identificar varias preocupaciones dentro de un sistema más grande que se puede separar en unidades modulares. El logro de una fuerte separación de preocupaciones dentro de un sistema requiere la creación de unidades significativas para la lógica y funciones de aplicación en todo el sistema. Las unidades más pequeñas facilitan a los equipos de entrega y mantenimiento de aplicaciones la tarea de comprender cómo y dónde realizar cambios, con una interrupción mínima en el sistema más grande. Las unidades más pequeñas también aclaran cómo y dónde centrarse en el trabajo al abordar la deuda técnica y contribuyen a la legibilidad general de su sistema.

Puede crear una mejor separación de preocupaciones en su organización de Salesforce orientando a la capacidad comercial y gestionando el estado.

Para sistemas de Salesforce, el mejor enfoque para la separación de preocupaciones aplica una perspectiva orientada hacia el negocio para identificar y organizar unidades modulares (o funciones) dentro del sistema. A diferencia de una vista centrada en ingeniería, que identifica unidades basándose en su función técnica. Una perspectiva orientada al negocio en la separación de preocupaciones requiere organizar el código y las personalizaciones en su sistema basándose en el servicio que proporcionan al negocio y a los usuarios comerciales. Adoptar este enfoque no significa ignorar el potencial de funciones técnicas redundantes o duplicadas en un sistema. Más bien significa que los servicios técnicos están claramente asignados a un principio de organización que en última instancia es transparente para el negocio.

La orientación a funciones comerciales ayuda a garantizar que las transferencias entre equipos de análisis comercial y descubrimiento a equipos de entrega sean lo más sencillas posible. Si los generadores de aplicaciones no tienen idea de dónde se asignan sus unidades de trabajo en su arquitectura comprimible, tiene un panorama de aplicaciones desordenado, no comprimible. Las asignaciones poco claras entre el estado final requerido por el negocio y las unidades modulares en una organización también aumentan las posibilidades de que los equipos de desarrollo o proveedores creen funciones redundantes en el sistema.

Considere lo siguiente para orientar las unidades funcionales a la capacidad comercial:

• Comience con trabajos por hacer. Céntrese en los trabajos por hacer (JTBD) de los usuarios y el negocio en sí. Pionero de Tony Ulwick, el enfoque de JTBD se centra en comprender el “trabajo”, o verdadero propósito, que las personas están tratando de lograr utilizando un producto o servicio. Es un nivel superior de abstracción que las tareas relacionadas con funciones de los usuarios o los pasos individuales en un proceso comercial. Por ejemplo, tareas como comprobaciones duplicadas y validaciones de direcciones podrían recaer en una función de orden superior de “establecer una única vista del cliente”. Después de tener una idea clara de estas funciones comerciales de orden superior, puede empezar a asignarles partes de su sistema.
• Orientar a funciones, no a estructuras de creación de informes. La jerarquía interna de sus unidades comerciales no es un proxy para funciones o trabajos significativos que se deben realizar. La jerarquía interna de su negocio tiene un impacto material en los procesos y las estructuras del equipo (por no mencionar los presupuestos). Esas son consideraciones logísticas importantes. Pero las necesidades funcionales del negocio operan en un nivel superior de abstracción que la logística. Si está creando un módulo para servir una estructura de creación de informes en vez de una función de orden superior, tenga en cuenta que es posible que tenga que realizar pasos adicionales para identificar cómo se relaciona ese módulo con las funciones comerciales.
• Sé iterativo. Comience asociándose con el negocio para identificar qué función podría funcionar para un producto mínimo viable (MVP). Cuando identifique una función, comience a crear ese MVP. A medida que construye, identifique los procesos, metadatos y eventos o mensajes que son fundamentales para la unidad funcional que está creando. Identifique cualquier proceso, metadatos y eventos o mensajes que sean dependencias externas. A medida que se diseñan unidades más funcionales, implemente la gestión de API y la gestión de dependencias para crear unidades que funcionen bien entre sí (en vez de crear unidades aisladas).

La lista de patrones y antipatrones a continuación muestra el aspecto de la orientación apropiada (y deficiente) a la función comercial en una solución de Salesforce. Puede utilizarlos para validar sus diseños antes de crear o identificar áreas de su sistema que necesitan ser refactorizadas.

Para obtener más información acerca de las herramientas disponibles en Salesforce para ayudarle a orientarse mejor a las funciones comerciales, consulte Herramientas relevantes para componible.

La gestión estatal se centra en el movimiento de información en un sistema en varios puntos en el tiempo. Una gestión de estado efectiva permite a las aplicaciones gestionar flujos complejos de datos o interacciones con un mínimo de resultados no planificados o indeterminados. Gestionar el estado en una organización modular de Salesforce significa crear rutas claras para flujos de lógica dentro y entre unidades, así como rutas elegantes para comportamientos de ejecución no planificados. La gestión de estado permite formar transmisiones coherentes de lógica desde unidades de aplicación modulares de Salesforce. En la mayoría de los casos, esto requiere interoperabilidad para estructurar el flujo de información entre unidades.

Las dificultades en la gestión del estado entre unidades acopladas de forma flexible a menudo conducen al desarrollo de aplicaciones monolíticas en Salesforce. Puede ver esto en grandes “monoflujos”, que se crean en un intento de orquestar un proceso complejo dentro de un flujo singular. Otro ejemplo son las clases masivas de Apex, que orquestan procesos complejos mediante códigos espagueti, o una larga serie de métodos de un solo uso. Estos tipos de arquitecturas de aplicación dificultan la refactorización y la depuración y aumentan los tiempos de incorporación para nuevos miembros del equipo o proveedores. También reducen el valor de las aplicaciones entregadas al negocio, ya que las funciones no son reutilizables.

Considere lo siguiente para gestionar el estado en una organización modular de Salesforce:

• Decida cuándo utilizar patrones con estado frente a sin estado. Los patrones con estado conservan información en una ruta de ejecución, mientras que los patrones sin estado no. En un sistema acoplado libremente, los patrones sin estado permiten que los componentes se refactoricen con mayor rapidez y con menos efectos secundarios. Sin embargo, los patrones sin estado no son apropiados para todos los casos de uso. Si está creando componentes para operaciones de datos, los patrones con estado pueden ayudar con la integridad y la coherencia de los datos en sus sistemas. Utilice un patrón con estado si su componente cumple cualquiera de los siguientes criterios:
  • La conciencia de la colocación dentro de una ruta de ejecución mayor es esencial para el comportamiento del componente.
  • El comportamiento del componente debe cambiar basándose en los resultados de una acción descendente (por ejemplo, debe cambiar la ejecución basándose en mensajes de reversión/error/éxito desde componentes descendentes)
  • El componente necesita esperar respuestas de un sistema externo o descendente para finalizar su trabajo
• Cree categorías significativas para información con estado. Estado es un término ambiguo que se puede aplicar a una gama tan amplia y profunda de información dentro (y más allá) de una organización de Salesforce que por sí mismo el término carece casi de sentido. Por lo tanto, un primer paso necesario para crear patrones de estado es crear categorías significativas para las rutas de ejecución de estado más importantes (o tipos de comportamientos de estado) dentro de su sistema. Algunas categorías a tener en cuenta:
  • Navegación y formularios
  • Operaciones de base de datos
  • Operaciones por lotes y masivas
  • Errores
• Defina estados relacionados con datos en términos de transacciones de base de datos. Los comportamientos integrados de la plataforma circunscribirán la mayoría de las consideraciones de estado para datos en Salesforce. No intente gestionar en contra o alrededor de este comportamiento. Diseñe para y con él. Diseñe soluciones que minimicen o eliminen la lógica de transacciones distribuidas. (Consulte la gestión de datos para obtener más detalles).
• Identifique estados que se producen dentro (y entre) unidades funcionales. A medida que reúne unidades funcionales en sistemas más grandes, tenga en cuenta cuándo está mezclando el comportamiento de componentes sin estado y con estado, y evite combinaciones que podrían crear bucles o brechas interminables en el procesamiento.
• Defina traspasos. Considere qué componentes de patrones de mensajería o eventos utilizarán para transmitir datos relacionados con el estado a otra parte del sistema. Asegúrese de que está creando conciencia de transacciones y gestionando sus componentes. No incluya ninguna lógica de transacción distribuida en sus transferencias.
• Cree asignaciones entre sus diagramas de proceso y estados. Los diagramas de proceso detallan los pasos que mueven la información por su sistema en varios puntos en el tiempo. Un diagrama de estado muestra los cambios reales en la información (el estado). Utilice la parte del pie de página de metadatos de los formularios de diagramas de Salesforce para capturar el estado cambiante de la información en cada paso de su proceso. Si separa diagramas de proceso y diagramas de estado, asegúrese de vincularlos. Este concepto no debe confundirse con la captura del estado actual y futuro de procesos o escenarios del sistema durante el diseño e implementación, ya que no se trata de la información que se mueve por el sistema.

La lista de patrones y antipatrones a continuación muestra el aspecto de la gestión de estado adecuada (y deficiente) en una solución de Salesforce. Puede utilizarlos para validar sus diseños antes de crear o identificar lugares en su sistema que necesitan ser refactorizados.

Para obtener más información acerca de las herramientas de Salesforce para gestionar el estado, consulte Herramientas relevantes para componer.

La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su solución.

✨ Descubra más patrones para la separación de preocupaciones en el Explorador de patrones y antipatrones.

En un sistema diseñado para la interoperabilidad, los componentes pueden intercambiar información y operar juntos de forma efectiva. La interoperabilidad es una clave para hacer que un sistema modular sea componible en vez de aislado. La interoperabilidad puede ser difícil de lograr en un sistema acoplado. Debe establecer estándares para métodos de integración coherentes que no socaven la independencia entre unidades y la separación de preocupaciones general en todo el sistema.

La interoperabilidad también afecta a la calidad de sus experiencias de usuario. Sus usuarios esperan que los datos creados en un área (como información de pedidos) sean utilizables en otra (como campañas de marketing) y sus generadores esperan que si aprenden a hacer algo (como crear un flujo o autenticarse en una API) encuentren que las técnicas familiares funcionan cuando pasan al siguiente problema. No diseñar para la interoperabilidad dará como resultado arquitecturas redundantes, datos replicados, ineficiencias de procesos y mayores costes de desarrollo y asistencia.

Puede crear interoperabilidad en sistemas modulares con mensajería y eventos, así como con gestión de API.

Los mensajes y eventos son dos formas en que puede activar componentes en un sistema para enviar y recibir información. En cuanto al contenido que pueden transportar, los eventos y los mensajes son similares. Una diferencia clave es el comportamiento del remitente. Un componente que envía un mensaje normalmente envía datos a un destino específico y espera algún tipo de respuesta del destinatario. Por el contrario, un componente emite un evento cuando sucede algo. No hay un destino específico ni una expectativa de una respuesta. Estas diferencias de comportamiento admiten diferentes patrones de comunicación. Los mensajes admiten patrones de comunicación con estado y los eventos admiten patrones de comunicación sin estado. (Consulte Gestión estatal para obtener más información acerca de esta distinción.)

Es importante alinear equipos en protocolos y casos de uso para mensajería y eventos. Los estándares poco claros pueden dar como resultado una mezcla de patrones en su sistema, lo que lleva a:

• Problemas de rendimiento y capacidad de ampliación donde se aplican patrones erróneos a un caso de uso específico
• Procesamiento incoherente que hace que el sistema parezca inestable para los usuarios finales
• Tiempos de solución de problemas más largos y procesos de mantenimiento más complejos

Tenga en cuenta lo siguiente cuando diseñe mensajes y eventos para crear estructuras acopladas de forma más flexible en su organización de Salesforce:

• Identifique casos de uso de sincronización y asíncrono. Eventos permite comunicaciones acopladas de forma libre, sin estado y asíncronas en un sistema. La mensajería permite patrones de comunicación más controlados, con estado y síncronos. Cuando decida cuándo utilizar mensajes o eventos, debe decidir si su comunicación debe ser síncrona (y potencialmente bloqueante) frente a asíncrona y no bloqueante.
• Defina cuidadosamente las estructuras de datos. La estructura de la información que los componentes pasan entre ellos es una parte importante para mantener un sistema acoplado de forma flexible gestionable y coherente. (Consulte API Management para obtener más información al respecto.) Una consideración clave al diseñar un mensaje o evento es la frecuencia con la que la estructura de la información puede necesitar cambiar. Una vez definido e implementado un mensaje o estructura de evento en su sistema, puede ser difícil gestionar actualizaciones, especialmente si el evento o mensaje ya se está utilizando para enviar información a un sistema externo.
• Mensajes de tamaño correcto. En general, es una práctica recomendada mantener tamaños de mensaje pequeños. Sin embargo, también existe un acto de equilibrio entre el tamaño de los mensajes y el volumen de los mensajes. Los sistemas pueden procesar cantidades menores de datos con mayor rapidez. El acto de procesamiento incluye una cantidad de gastos generales adicionales ya que los destinatarios tienen que desempaquetar, interpretar y determinar qué hacer con la información que recibieron. Estos pasos pueden tardar una cantidad insignificante de tiempo en completarse, pero pueden crear una carga en los sistemas a escala. Evite los diseños que requieren que los componentes del sistema procesen varios mensajes pequeños de forma sucesiva para completar un trabajo. Para ajustar el tamaño de sus mensajes, piense en diseñar para el mínimo de datos que los componentes descendentes necesitarán para procesar correctamente y actuar sobre la información que se envió, sin asumir también que cada componente descendente será capaz de solicitar o procesar numerosos mensajes de seguimiento.
• Diseño para escalabilidad. Los componentes acoplados de forma holgada pueden facilitar la ampliación de su arquitectura. La eliminación de dependencias entre componentes permite a los equipos trabajar en la mejora del rendimiento o la capacidad de ampliación de cualquier componente individual con efectos mínimos en los demás. Sin embargo, los componentes poco acoplados también introducen una complejidad significativa en su arquitectura a escala (especialmente cuando se trata de gestionar el estado). Identifique procesos que necesitan tener una lógica o dependencias acopladas más estrechamente por razones de integridad de datos o experiencia de usuario válidas y no intente introducir patrones basados en eventos/asíncronos en esos procesos. Utilice patrones basados en sincronización/mensajes y una gestión de errores apropiada en su lugar.

La lista de patrones y antipatrones a continuación muestra el aspecto adecuado (y deficiente) de la mensajería y los eventos en una solución de Salesforce. Puede utilizarlos para validar sus diseños antes de crear o identificar lugares en su sistema que necesitan ser refactorizados.

Para obtener más información acerca de herramientas de mensajería y eventos de Salesforce, consulte Herramientas relevantes para componible. Para obtener más información acerca de la selección de un patrón o herramienta de eventos para un caso de uso concreto, consulte la Guía del arquitecto sobre arquitectura dirigida por eventos con Salesforce.

La creación de una gestión adecuada de la interfaz de programación de aplicaciones (API) en una solución de Salesforce permite que los componentes individuales de su sistema sigan patrones de comunicación predecibles. Salesforce proporciona API integradas y seguras para utilizar para la comunicación con sistemas externos a Salesforce. (Para obtener más información sobre las API de Salesforce Platform, consulte Conceptos básicos de Arquitectura.)

Una gestión de API efectiva dentro de las soluciones de Salesforce es clave para crear arquitecturas realmente componibles. Permite a los componentes de una organización de Salesforce enviar y recibir información de forma eficiente. También permite a los generadores de soluciones seguir protocolos claros sobre cómo se comunican los componentes que crean con otros componentes en el sistema, y les ayuda a identificar implementaciones deficientes de forma temprana. Además, permite a los generadores de soluciones centrarse más estrictamente en el componente concreto que están creando o refactorizando, lo que aumenta la productividad y la calidad.

Gestión de API a nivel empresarial es un tema separado, y se logra mejor con una herramienta de Gestión de API integral. (Para obtener más información sobre la perspectiva de MuleSoft en este tema, consulte ¿Qué es Gestión de API?).

Considere lo siguiente para crear funciones de gestión de API en sus soluciones de Salesforce:

• Piense en las API como patrones predecibles o contratos para la comunicación. El tipo de datos de variables de entrada o salida, los nombres de variables, los elementos de información que deben (o no) aparecer en un patrón específico: estas son las claves para una gestión de API efectiva. Estas definiciones deben aparecer en sus estándares de diseño y los equipos deben poder averiguar cómo se implementaron estas definiciones en partes concretas de su sistema a través de su documentación. Una forma de ver dificultades combinando cambios de nuevo desarrollo en un entorno de integración es mirarlos como evidencia de dónde implementó mal comunicaciones de API (o quizás ninguna definición de API en absoluto).

• No limite su pensamiento sobre las API al código exclusivamente. Lo que define una API en este contexto es la coherencia de las estructuras y variables de mensajes dentro de ese mensaje. Siempre que se mantenga esa coherencia, se puede implementar una API en código así como en personalizaciones declarativas, como flujos iniciados automáticamente modulares (o desencadenados por eventos de plataforma) o incluso plantillas de flujo. Basa sus decisiones en qué definir en código frente a en flujos no en implementación de API sino en capacidad de empaquetado y prueba.

• Mantenga su ciclo de vida y versión sencillos. Como todas las partes del desarrollo de aplicaciones, las API tienen un ciclo de vida: definir, crear, probar, implementar y mantener (incluyendo retirarse). Las API de Salesforce Platform publican varias versiones en un año natural, debido al ciclo de lanzamiento rápido de la plataforma. (Puede leer más sobre este comportamiento en Conceptos básicos de Salesforce Archhitecture.) Esto significa que las API de plataforma tienen un ciclo de vida bastante complejo, ya que es necesario mantener varias versiones de una API concreta y están disponibles para los clientes de Salesforce. Este nivel de complejidad es apropiado para casos de uso de PaaS, pero lo más probable es que sea una complejidad innecesaria para sus arquitecturas de soluciones en plataforma (consulte: Antipatrones de reajustabilidad). Céntrese en definir un propósito claro para una API (por ejemplo, gestión de errores) y defina claramente la línea base. Procure tener solo una versión de cada API.

• Haga que sus API sean detectables, accesibles y gestionables. Documente sus API de modo que los consumidores potenciales puedan encontrar API disponibles conectadas a ellas fácilmente. Las API deben funcionar correctamente como parte de un conjunto de capacidades.

• Sé iterativo. Céntrese en definir e implementar solo una API interna a la vez. De ese modo, puede centrarse en iterar la definición de API rápidamente, encontrar el formulario correcto para su única versión compatible y establecer prácticas recomendadas desde la experiencia de implementación.

La lista de patrones y antipatrones a continuación muestra el aspecto de la gestión de API adecuada (y deficiente) en una solución de Salesforce. Puede utilizarlos para validar sus diseños antes de crear o identificar áreas de su sistema que necesitan ser refactorizadas.

Para obtener más información acerca de las herramientas disponibles en Salesforce para ayudarle a crear más interoperabilidad, consulte Herramientas relevantes para componible.

La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su solución.

✨ Descubra más patrones de interoperabilidad en el Explorador de patrones y antipatrones.

La creación de capacidad de empaquetado en una organización de Salesforce significa que las funciones en la organización provienen de unidades que se pueden desarrollar e implementar de forma independiente y fiable, como paquetes. Idealmente, estas unidades se definen como un tipo de paquete de segunda generación (ya sea un paquete desbloqueado o gestionado para ISV). Nota: Como las soluciones bien diseñadas utilizan estos tipos de paquetes exclusivamente, los paquetes gestionados de primera generación no se tratan aquí.

Una cosa es definir separaciones de preocupaciones y crear unidades funcionales en una organización de Salesforce. Otra cosa es desenredar y gestionar dependencias con la claridad suficiente para versionar correctamente esas unidades como artefactos de paquete. Alcanzar ese nivel de estabilidad y aislamiento de metadatos requiere un nivel significativo de madurez de DevOps (y arquitectónica). También acelera el tiempo de desarrollo, mejora las experiencias del generador de aplicaciones y aporta previsibilidad y control a las versiones y la gestión de versiones. No todas las organizaciones podrán dar cobertura a la infraestructura necesaria para definir, mantener y desarrollar paquetes efectivos. Pero lograr la empaquetabilidad debe ser el objetivo final para casi todas las organizaciones de Salesforce.

Puede crear capacidad de empaquetado en sus soluciones de Salesforce centrándose en el acoplamiento suelto y la gestión de dependencias.

En un sistema con acoplamiento suelto, las piezas individuales no están fuertemente unidas entre sí. Muchas de las ventajas de un sistema componible provienen del acoplamiento suelto. En sistemas empaquetables, lograr un acoplamiento suelto entre paquetes (e instalar organizaciones) le permitirá tener paquetes bien definidos y ciclos de desarrollo más productivos para equipos que trabajan con paquetes.

En Salesforce Platform, puede crear paquetes acoplados estrechamente a una organización concreta. Esta función es útil para definir unidades funcionales y experimentar con la correcta separación de preocupaciones en su organización, a medida que progresa en la madurez del empaquetado. Sin embargo, si elige este enfoque, se dará cuenta de algunos de los beneficios de los metadatos realmente empaquetables, incluyendo el desarrollo dirigido por el origen, la capacidad de utilizar versiones y la estabilidad de artefactos. En su lugar, es probable que siga experimentando los inconvenientes de un sistema estrechamente acoplado, incluyendo:

• Puntos únicos de fallo que causan interrupciones y problemas de rendimiento
• Implementaciones lentas e impredecibles
• Ciclos de depuración y solución de problemas complejos y difíciles
• Problemas de escala y rendimiento

El objetivo final para cualquier sistema de Salesforce empaquetable es paquetes acoplados de forma flexible.

Tenga en cuenta lo siguiente cuando vea la separación de sus metadatos de Salesforce en paquetes efectivos:

• Qué personalizaciones son los datos frente a los metadatos. Cuando se trata de la empaquetabilidad, Salesforce Platform trata los datos y metadatos de forma muy diferente. Es importante comprender qué funciones de su organización son metadatos o datos. No puede incluir datos en ninguna unidad empaquetada. Cuando decida dónde empezar a abstraer funciones en una unidad empaquetada, sus equipos tendrán que decidir si las personalizaciones almacenadas como datos deben excluirse del paquete por completo o refactorizarse en una implementación basada en metadatos.
• Cómo afectará el empaquetado a los equipos. Una realidad logística del empaquetado de Salesforce es que gran parte del trabajo de producción y lanzamiento de una versión de paquete requiere habilidades con las tecnologías Salesforce CLI y/o CI/CD. Esto significa que las personalizaciones de código bajo y programáticas por igual requerirán tiempo y atención de alguien capaz de trabajar con tecnología de DevOps relacionada con paquetes. Dependiendo de cómo gestiona su equipo la entrega de funciones, la adopción de paquetes puede suponer ralentizaciones o bloqueos significativos para diferentes equipos en una organización. Tendrá que identificar si los equipos podrán gestionar la entrega de funciones a través del empaquetado y realizar un plan para solucionar cualquier déficit de habilidades o plantilla. Las soluciones podrían incluir la adopción de programación emparejada o la implementación de trabajos de CI/CD para entornos de desarrollo.
• Cómo cambiará el empaquetado las estrategias ambientales. En un ciclo de vida de desarrollo dirigido por paquetes, el trabajo temprano debe realizarse en organizaciones borrador. Estos entornos de desarrollo temporales dirigidos por origen permiten ciclos más rápidos e iterativos. También admiten controles de acceso a entornos más granulares para sus equipos de desarrollo y un mayor aislamiento de la producción. Cuantas más dependencias tengan sus paquetes de metadatos o datos no empaquetados que solo existan en un entorno sandbox o de producción, menos probabilidades tendrán los equipos de utilizar organizaciones borrador. Puede activar el seguimiento de origen en entornos sandbox para permitir patrones de desarrollo dirigidos por origen en entornos de organizaciones que no son borrador, pero sus equipos de desarrollo no se beneficiarán de la velocidad y la velocidad iterativa de las organizaciones borrador.
• Cómo se relacionan las versiones de paquete con versiones. Planifique con qué frecuencia y en qué etapa del desarrollo debe producirse la versión del paquete. Las solicitudes de versión de paquetes están limitadas (por organización) de forma escalonada durante 24 horas. Como práctica recomendada general, solo versione un paquete cuando esté seguro de que ninguno de los contenidos del paquete necesita cambiar. Idealmente, aprovisionará versiones de paquete después de que se completen los procesos de garantía de calidad. No permita que los equipos de desarrollo utilicen el éxito o el fracaso de las solicitudes de creación de paquetes como “pruebas” de lo bien que definieron los límites de paquetes. Existen formas de hacerlo sin intentar versionar un artefacto de paquete.
• Lo que el estado final ideal debería admitir. La estrategia de empaquetado ideal permite versiones estables y controladas de Salesforce que se pueden desarrollar y entregar rápidamente. La definición de demasiados paquetes en su organización puede generar nuevos tipos de complejidades y cuellos de botella para los equipos de desarrollo. Una organización demasiado modularizada también puede hacer que las versiones sean lentas y difíciles. Comience con la creación y publicación de algunas versiones de un paquete único y significativo. Derive paquetes de seguimiento de forma incremental. Deje de introducir paquetes cuando tenga una cadencia de lanzamiento que sirva bien a su negocio. Refactorice paquetes con el tiempo, si las necesidades comerciales cambian o la calidad de la versión disminuye. El estado final del paquete ideal es subjetivo.

Independientemente de cómo decida definir sus paquetes, solo versionará con éxito un paquete acoplado de forma flexible a través de una gestión de dependencias efectiva.

La lista de patrones y antipatrones a continuación muestra el aspecto apropiado (y deficiente) del acoplamiento suelto para el empaquetado de Salesforce. Puede utilizarlos para validar sus diseños antes de crear o identificar áreas de su sistema que necesitan ser refactorizadas.

Para obtener más información acerca de herramientas de Salesforce para ayudarle a crear más empaquetabilidad, consulte Herramientas relevantes para componible.

En el contexto de una solución de Salesforce, la gestión de dependencias significa identificar y estructurar las relaciones entre los metadatos en sus paquetes y los metadatos en las organizaciones en las que se instalarán esos paquetes. La gestión de dependencias es una parte clave del desarrollo de artefactos de paquetes estables.

Las dependencias pueden estar en conflicto con los esfuerzos para crear unidades funcionales perfectamente separadas y acopladas. En un estado de ingeniería ideal, un sistema acoplado libremente no tiene dependencias entre unidades. Sin embargo, en el mundo real, eliminar todas las dependencias no es práctico.

A menudo, el equilibrio entre hacer que los sistemas sean legibles y utilizar unidades funcionales pensadas para las empresas requiere una compensación en términos de aislamiento perfecto entre las unidades de un sistema. Más pragmáticamente, los servicios principales proporcionados por la funcionalidad estándar de Salesforce Platform crean dependencias positivas netas clave para cualquier solución de Salesforce. Muchas ventajas de escalabilidad, rendimiento y seguridad integradas provienen de la profundidad con la que están integradas en la plataforma. Cuando diseñe soluciones de Salesforce empaquetables, es importante recordar que las dependencias de paquetes no son inherentemente malas. La mala gestión de dependencias es mala.

Una gestión de dependencias eficaz con el empaquetado de Salesforce significa que los equipos de desarrollo y mantenimiento pueden:

• Incorporación a nuevos proyectos con mayor rapidez y acceso limitado al entorno
• Desarrollar y probar cambios rápidamente
• Comprender cómo se deben entregar funciones complejas en compromisos específicos más pequeños
• Controle las cadencias de lanzamiento y reduzca los plazos de mantenimiento/apagón del sistema
• Revertir previsiblemente cambios adversos en cualquier entorno

Las técnicas para la gestión de dependencias con Salesforce son bastante sencillas:

• Utilice mensajería y eventos para gestionar transferencias de información con estado o sin estado entre componentes.
• Utilice tipos de metadatos personalizados para proporcionar información dinámica en tiempo de ejecución y para admitir patrones de inyección de dependencias.
• Haga que los desarrolladores Apex utilicen clases abstractas o virtuales.

Al final, tendrá que decidir los patrones de diseño permitidos en su organización en el desarrollo declarativo y programático. Las consideraciones más importantes (arquitectónicamente) son definir dónde desea agregar más complejidad de ingeniería para tener menos dependencias y dónde necesita tolerar más dependencias para simplificar los flujos de trabajo del generador de aplicaciones.

A medida que construye estrategias de gestión de dependencias en sus paquetes, considere los dos principios de organización principales para unidades de paquete: horizontal y vertical.

• Límites horizontales. En paradigmas horizontales, la funcionalidad que podría necesitar más de un paquete se abstrae en una capa horizontal. Las capas horizontales se convierten entonces en el origen de funciones comunes y se accede a ellas a través de una dependencia declarada. La minimización de funciones redundantes entre paquetes se favorece sobre la minimización de dependencias.
• Límites verticales. Los paradigmas verticales maximizan el aislamiento y el acoplamiento suelto entre partes del sistema. Las funciones compartidas están limitadas y podría aparecer trabajo similar entre unidades. Las dependencias están estrictamente limitadas, con el fin de maximizar el aislamiento entre unidades de paquete.

Tenga en cuenta que esto no es una decisión. Puede mezclar paradigmas verticales y horizontales según sea necesario. A menudo, la forma más rápida de empezar con un paquete es crear capas de servicio horizontales. A medida que crece la escala y la complejidad de la adopción de su paquete, abstraer más unidades verticales ayudará a simplificar procesos de configuración de entornos complejos o la incorporación de desarrolladores.

Un sistema con dos unidades funcionales (A y B), por ejemplo, puede estructurarse con dependencias de paquetes dispuestas en paradigmas híbridos verticales, horizontales y verticales-horizontales.

Independientemente del paradigma de organización de paquetes que elija, hay algunos absolutos a tener en cuenta:

• No duplique metadatos entre paquetes. Los metadatos necesarios para más de un paquete deben abstraerse en uno o más paquetes declarados como dependencias.
• Aproveche las dependencias integradas de los metadatos de Salesforce Platform. Para los generadores de aplicaciones, los servicios integrados que ofrece Salesforce Platform proporcionan una gran cantidad de funciones que se pueden configurar rápidamente. Muchos de estos servicios tienen dependencias integradas que dificultan la abstracción en unidades funcionales de bajo nivel. Para un tipo de metadatos específico, debe comprender dónde recae en el espectro de dependencias integradas y utilizar este entendimiento para definir sus cadenas de dependencia de paquetes. No inicie la adopción de paquetes intentando forzar el acoplamiento suelto en una parte de la funcionalidad de plataforma estándar con muchas dependencias integradas. Agregará complejidad (no valor) a medida que alcance funciones de orden superior. También es otra forma de caer en antipatrones estándar frente a personalizados. Empaquete metadatos desde abajo (menos dependencias) hacia arriba e itérelos a lo largo del tiempo.
• Cuidado con sus cadenas de dependencias. Evite crear cadenas de dependencia de paquetes que requerirán que los desarrolladores dividan sus cambios en muchos paquetes diferentes en cualquier momento.
• Piense en lo que tiene sentido para el control de origen. Existen dos formas básicas de gestionar sus paquetes en el control de origen. El primero es un monorrepo único con paquetes aislados dentro de carpetas. El segundo es múltiples repos con paquetes aislados en sus propios repos. Existen complejidades para gestionar cada tipo de estrategia de origen, a largo plazo. En términos de incorporación de desarrollador, los límites verticales son más eficientes en múltiples paradigmas de repositorio. Los límites horizontales son más comprensibles en un monorrepo. De nuevo, puede mezclar y comparar estrategias a medida que madura su arquitectura.

La lista de patrones y antipatrones a continuación muestra el aspecto de la gestión de dependencias adecuada (y deficiente) con paquetes de Salesforce. Puede utilizarlos para validar sus diseños antes de crear o identificar áreas de su sistema que necesitan ser refactorizadas.

Para obtener más información acerca de herramientas de Salesforce para la gestión de dependencias, consulte Herramientas relevantes para componible.

La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su solución.

✨ Descubra más patrones para la empaquetabilidad en el Explorador de patrones y antipatrones.

Ayúdenos a mantener Salesforce Well-Architected relevante para usted; realice nuestra encuesta para proporcionar comentarios sobre este contenido y díganos qué le gustaría ver a continuación.