Lea sobre nuestras programaciones de actualizaciones aquí.

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

Los sistemas componibles permiten a las empresas adaptarse con mayor rapidez y estabilidad, independientemente de que el estímulo sea interno de la empresa o causado por factores externos. La componibilidad 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 sola 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 diversas preocupaciones dentro de un sistema más grande que puede separarse 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 dejan más claro cómo y dónde centrar 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 de negocio y gestionando el estado.

Para sistemas de Salesforce, el mejor enfoque para la separación de preocupaciones aplica una perspectiva orientada al negocio para identificar y organizar unidades modulares (o funciones) dentro del sistema. Esto no se parece a 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 los usuarios de negocio. Adoptar este enfoque no significa ignorar el potencial de funciones técnicas redundantes o duplicadas en un sistema. En su lugar, 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 de negocio ayuda a garantizar que las transferencias entre equipos de análisis de negocio 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 componible, tiene un panorama de aplicaciones desordenado, no componible. 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 construyan funciones redundantes en el sistema.

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

• Comience con trabajos por hacer. Céntrese en los trabajos por hacer (JTBD) de los usuarios y el negocio en sí. Con Tony Ulwick a la vanguardia, el enfoque de JTBD se centra en comprender el “trabajo”, o propósito verdadero, que las personas están intentando lograr utilizando un producto o servicio. Es un nivel de abstracción superior a las tareas relacionadas con funciones de los usuarios o los pasos individuales en un proceso de negocio. 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 de negocio de orden superior, puede comenzar a asignarles partes de su sistema.
• Oriente a funciones, no a estructuras de creación de reportes. La jerarquía interna de sus unidades de negocio no es un proxy para funciones significativas o trabajos por hacer. 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 de abstracción superior a la logística. Si está creando un módulo para servir una estructura de creación de reportes 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 de negocio.
• 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 centrales 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 funcionan bien entre sí (en vez de crear unidades en silos).

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

Para obtener más información acerca de las herramientas disponibles de Salesforce para ayudarle a orientarse mejor a las funciones de negocio, 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. La 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 llevan 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 poco acoplado, los patrones sin estado permiten refactorizar componentes con mayor rapidez y 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 ubicación en una ruta de ejecución superior 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 amplia gama 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. Un primer paso necesario para crear patrones con estado, por lo tanto, es crear categorías con sentido para las rutas de ejecución con estado más importantes (o tipos de comportamientos con estado) en 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 tratamiento en 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 panoramas del sistema durante el diseño y la 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 construir o identificar lugares en su sistema que necesitan refactorizarse.

Para obtener más información acerca de las herramientas de Salesforce para gestionar el estado, 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 correcció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 poco 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 constructores esperan que si aprenden a hacer algo (como crear un flujo o autenticarse en una API) encuentren que las técnicas familiares funcionan cuando pasen al siguiente problema. No diseñar para la interoperabilidad dará como resultado arquitecturas redundantes, datos replicados, ineficiencias de procesos y costos de desarrollo y asistencia aumentados.

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 términos del 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 desempeño 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. Al decidir cuándo utilizar mensajes o eventos, debe decidir si su comunicación debe ser síncrona (y posiblemente bloqueada) frente a asíncrona y no bloqueada.
• Defina estructuras de datos cuidadosamente. 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 mejor práctica mantener tamaños de mensaje pequeños. Sin embargo, también existe un acto de equilibrio entre el tamaño del mensaje y el volumen del mensaje. 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 una pieza de 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 poco acoplados pueden facilitar la ampliación de su arquitectura. La eliminación de dependencias entre componentes permite a los equipos trabajar en la mejora del desempeño 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 estado). Identifique procesos que necesitan tener una lógica o dependencias más estrechamente acopladas 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/mensajería y la 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 construir o identificar lugares en su sistema que necesitan refactorizarse.

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 de interfaz de programación de aplicaciones (API) apropiada dentro de 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 fuera de Salesforce. (Para obtener más información sobre las API de Salesforce Platform, consulte Fundamentos de arquitectura.)

Una gestión de API efectiva en 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 potencia la productividad y la calidad.

Gestión de API a nivel de compañía 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 deben) aparecer en un patrón concreto: 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 desde nuevo desarrollo en un entorno de integración es mirarlos como evidencia de dónde tiene comunicaciones de API mal implementadas (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 en 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 versiones sencillos. Como todas las partes del desarrollo de aplicaciones, las API tienen un ciclo de vida: definir, crear, probar, implementar y mantener (incluyendo la retirada). Las API de Salesforce Platform lanzan 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 Fundamentos de arquitectura de Salesforce.) 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 que 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 reaptitud). Céntrese en definir un propósito claro para una API (por ejemplo, tratamiento 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 que se conecten a ellas fácilmente. Las API deben funcionar sin problemas como parte de un panorama 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 mejores prácticas 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 construir o identificar áreas de su sistema que necesitan refactorizarse.

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 correcció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 paquetes. 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. Sin embargo, el objetivo final para casi todas las organizaciones de Salesforce debe ser alcanzar la capacidad de empaquetado.

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 atadas entre sí. Muchas de las ventajas de un sistema componible se derivan 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 ajustados 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 avanza en la madurez del empaquetado. Sin embargo, si elige este enfoque, se dará cuenta de algunos de los beneficios de los metadatos que se pueden empaquetar realmente, 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 desempeño
• Implementaciones lentas e impredecibles
• Ciclos de depuración y solución de problemas complejos y difíciles
• Problemas de escala y desempeño

El objetivo final para cualquier sistema de Salesforce empaquetable son 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 los 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 comenzar 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 gestione 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 medioambientales. 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 en metadatos no empaquetados o datos que solo existen en un entorno sandbox o de producción, menos posibilidades 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 paquetes con las 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 mejor práctica general, solo versione un paquete cuando esté seguro de que ninguno de los contenidos del paquete necesita cambiar. Idealmente, aprovisionará versiones de paquetes 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 fallo de las solicitudes de creación de paquetes como “pruebas” de lo bien que definieron los límites de los paquetes. Existen formas de hacerlo sin intentar versionar un artefacto de paquete.
• Lo que el estado final ideal debe admitir. La estrategia de empaquetado ideal permite versiones controladas y estables 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 el lanzamiento de algunas versiones de un único paquete con sentido. Derive paquetes de seguimiento de forma incremental. Deje de introducir paquetes cuando tenga una cadencia de versión que sirva bien a su negocio. Refactorice paquetes con el tiempo, si las necesidades de negocio 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 del acoplamiento suelto adecuado (y deficiente) para el empaquetado de Salesforce. Puede utilizarlos para validar sus diseños antes de construir o identificar áreas de su sistema que necesitan refactorizarse.

Para obtener más información acerca de herramientas de Salesforce para ayudarle a crear más capacidad de empaquetado, 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 desacuerdo 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, la eliminación de todas las dependencias no es práctica.

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. De forma más pragmática, 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, desempeño y seguridad integradas provienen de la profundidad de su integración en la plataforma. Cuando diseñe soluciones de Salesforce empaquetables, es importante recordar que las dependencias del paquete no son inherentemente malas. La mala gestión de dependencias es mala.

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

• Incorporación a nuevos proyectos más rápido y con acceso de entorno limitado
• 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 versiones y reduzca los plazos de mantenimiento/corte de versiones del sistema
• Revertir cambios adversos de forma predecible 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 elegantes de información con estado o sin estado entre componentes.
• Utilice tipos de metadatos personalizados para proporcionar información de tiempo de ejecución dinámica y para admitir patrones de inyección de dependencias.
• Haga que los desarrolladores Apex utilicen clases abstractas o virtuales.

Al final, deberá 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, las funciones que podrían necesitar más de un paquete se abstraen 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. Minimizar las funciones redundantes entre paquetes se favorece sobre minimizar las 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 es posible que aparezca 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, la abstracción de 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 concreto, 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 un elemento de 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 en carpetas. El segundo es múltiples representantes con paquetes aislados en sus propios representantes. Existen complejidades en la gestión de 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 monodepósito. De nuevo, puede mezclar y combinar 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 construir o identificar áreas de su sistema que necesitan refactorizarse.

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 correcció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 e indicarnos qué le gustaría ver a continuación.