Comprender la Separación de intereses

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

• Explicar el valor de negocio de la adopción de la separación de intereses.
  
• Utilizar SOC para adaptar su solución a cambios en requisitos de usuario o tecnologías de plataforma.
  
• Aplicar SOC al desarrollo de Salesforce.
  
• Determinar cuándo aplicar SOC.
  

Introducción

Se hace referencia a menudo al software, como los peinados, como una entidad viva que cambia y evoluciona con el tiempo. Desde la ameba unicelular de un programa "Hola mundo", a la complejidad de software a nivel empresarial, el tipo y la variedad en vida también se produce en el software. Organismos complejos desarrollan sistemas para fines especializados. Esqueletos, músculos y órganos funcionan como una unidad, pero también interactúan con otros sistemas para beneficiarse de todo.

Lo mismo es aplicable a aplicaciones de negocio complejas. La separación de los diferentes intereses en diferentes sistemas o capas facilita la navegación y el mantenimiento de códigos. Cuando se realizan cambios, los impactos y las regresiones en otras áreas se minimizan y evoluciona un programa más adaptable y positivo.

Siga el proceso con Trail Together

¿Desea seguir el proceso con un experto a medida que realiza este paso? Mire este video que forma parte de la serie Trail Together.

Separación de intereses (SOC)

Codey el oso dice a menudo, "El mejor código se redacta lejos del teclado". Ésta es otra forma de decir que un buen código se beneficia de un diseño y una previsión cuidadosos. Tenga en cuenta esta recomendación al planificar dónde poner su código. ¡La codificación debe ser sencilla cuando conoce la ruta que va a tomar!

El código complejo se va de las manos cuando no lo divide correctamente. Cuando un código se entremezcla, se vuelve propenso a cometer errores, difícil de mantener o difícil de aprender. ¿Alguna vez intentó depurar el código espagueti de alguien? ¡Además, los problemas empeoran cuando incorpora nuevos desarrolladores en la fiesta! ¡La creación de módulos o bibliotecas para compartir cálculos comunes y procesos entre diferentes partes de su aplicación es a menudo el primer paso en reutilización de código, que es, por supuesto, algo bueno!

¿SOC es entonces una palabra sofisticada para la reutilización de códigos?

Sí... y no. SOC requiere algunas reflexiones anticipadas acerca de la instalación interna de su aplicación, incluidas convenciones de nomenclatura de clases y directrices de codificación. Desea que esta planificación perdure y que sea en parte autodescriptiva para otros. Un buen código debe narrar una historia. El enfoque usual de la reutilización de códigos es mover fragmentos de código alrededor en cuanto lo necesiten dos o más áreas. El código es a menudo ubicado en clases de MyUtil u otras áreas de volcado genérico. Lo que está bien, y seguramente recomendado para copiar y pegar.

¿Cuáles son las ventajas de SOC?

A un nivel alto, las aplicaciones tienen tres cosas: almacenamiento, lógica y un significado para interactuar con ellas, ya sea por humanos, criaturas del bosque u otras aplicaciones. Cuando separa estas cosas, puede comenzar a definir capas en su aplicación, cada una con su propio conjunto de intereses y responsabilidades en otras capas y la aplicación en conjunto. La consideración y gestión cuidadosa de estas capas es importante para la adopción de SOC.

• Evolución. Con el tiempo, conforme la tecnología, la comprensión y los requisitos (tanto funcionales como técnicos) evolucionan, una capa podría requerir ampliación, adaptación o incluso disminución. Eche un vistazo a la tecnología de interfaz de usuario a lo largo de los últimos 10 años como un ejemplo principal. ¿Cuántos marcos de trabajo de JavaScript puede calcular antes de repartir?
  
• Gestión de impacto. La modificación o disminución de una o más capas no debería afectar indebidamente a otras capas, a menos que sea la intención debido a requisitos.
  
• Funciones y responsabilidad. Cada capa tiene su propia responsabilidad y no debe disminuir o ampliar esa responsabilidad. Por ejemplo, disminuir la biblioteca o tecnología de un cliente en favor de otra no significa perder la lógica de negocio, porque ésta es la responsabilidad de otra capa. Si las líneas de responsabilidad se desdibujan, el fin el valor de SOC se debilitan y eso no es bueno.
  

Salesforce Platform tiene dos enfoques distintos sobre el desarrollo: codificación declarativa (apuntar y hacer clic) y tradicional. Puede utilizar cualquier método por su cuenta o en conjunto. Los dos enfoques se incluyen en las capas de SOC estándar como se describe a continuación.

Presentación

• Declarativa: diseños, páginas de registro, flujo, tipos de registro, fórmulas, reportes, tableros
  
• Codificación: Controladores de Apex, Visualforce, Componentes Lightning
  

Capa de lógica de negocio

• Declarativa: fórmula, flujo, reglas de validación, reglas de intercambio, procesos de aprobación
  
• Codificación: servicios de Apex, acciones personalizadas de Apex, Apex asíncrono
  

Capa de acceso a los datos

• Declarativa: cargadores de datos, Salesforce Connect
  
• Codificación: SOQL, SOSL, API de Salesforce
  

Capa de base de datos

• Declarativa: Objetos personalizados, Campos, Relaciones, Acumulaciones
  
• Codificación: Desencadenadores de Apex
  

Cuándo no necesita SOC en Salesforce

Una ventaja clave de Salesforce es su modelo de desarrollo declarativo que permite crear objetos, campos, diseños, reglas de validación, flujos de trabajo, campos de fórmula y mucho más, sin tener que escribir una sola línea de código. El desarrollo declarativo es más rápido y sencillo, y ya implementa un grado de SOC. Si su aplicación está altamente centrada en datos, y puede entregar una gran parte de su aplicación de forma declarativa, no vuelva a inventar la rueda, ¡solo utilícela!

Aunque no es código, lo que puede alcanzar con el desarrollo declarativo es todavía una capa de arquitectura en su aplicación, cosa que trataremos más adelante.

Cuándo usar SOC en Salesforce

Si su aplicación está centrada en el proceso o se ve forzado a implementar cálculos más complejos, validaciones o experiencias de interfaz de usuario mejoradas, se adentrará en el país de código de Apex. Salesforce ofrece muchos lugares para ubicar el código de Apex, como desencadenadores, clases que incluyen métodos @AuraEnabled, API, Apex por lotes y controladores de email.

Puede realizar una gran inversión en el desarrollo y las pruebas de código, pero es la lógica de negocio a la que debe dedicar su protección. Más adelante veremos algunas directrices para escribir lógica de negocios, pero por ahora pensemos en las siguientes instancias para usar SOC en Salesforce.

• Sustitución o incorporación de otra interfaz de usuario a su aplicación: Considere la cantidad de código que necesita para volver a redactar que no tenga nada que ver con la interfaz de usuario, pero afecta a la función de inserción, actualización, validación y cálculo de su aplicación.
  
• Proporcionar una API de cara al público a su lógica: Evalúe qué partes de su base de código existente debe llamar para implementar la API. ¿El uso de métodos @AuraEnabled es una buena base para una API? (La respuesta es no.)
  
• Ampliación de su lógica de aplicación a través de Apex por lotes: Si necesita continuar para proporcionar una experiencia interactiva (para volúmenes reducidos) a través de su interfaz de usuario existente, ¿cómo compartiría la lógica entre los dos para asegurarse de que el usuario obtiene resultados coherentes independientemente del tamaño?
  
• Trabajar con lógica compleja en sus controladores Visualforce o métodos @AuraEnabled: ¿su código se ocupa de algo más que enviar y recibir información del usuario? Con Componentes Lightning y Visualforce, puede dividir su código a través de Modelo–Vista–Controlador (MVC), un formulario de SOC para desarrollo de cliente. Sin embargo, el uso de controladores para todo su código no garantiza que esté siguiente SOC en términos de su lógica de negocio.
  
• Facilitar a los nuevos desarrolladores la tarea de encontrar su camino alrededor de base de código: ¿Cuánto tiempo necesita un desarrollador para averiguar dónde colocar nuevos códigos y buscar comportamientos existentes?
  

Dependiendo de dónde redactó su código, quizás ya esté en buenas condiciones para abordar algunos de los escenarios siguientes. Si no, o si solo siente curiosidad, las próximas unidades aportan algo de luz a posteriores reflexiones. La siguiente tabla también puede ayudar a decidir si utilizar estos patrones basándose en el tamaño y el ámbito de la solución que está creando.

Recursos

• Separation of Concerns (Wikipedia)
• Martin Fowler’s Enterprise Architecture Patterns