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 Force.com.
• 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.

La plataforma Force.com tiene dos enfoques diferentes para 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: Formatos, 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, Validación, Flujo de trabajo, Reglas de colaboración
• Codificación: Servicios de Apex, Acciones personalizadas de Apex

Capa de acceso a los datos

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

Capa de base de datos

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

Cuando no necesita SOC en Force.com

Una ventaja clave de Force.com es su modelo de desarrollo declarativo que le permite crear objetos, campos, formatos, reglas de validación, flujos de trabajo, campos de fórmula y mucho más sin redactar una sola línea de códigos. 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 utilizar SOC en Force.com

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. Force.com proporciona varias ubicaciones para colocar el código de Apex, como desencadenadores, controladores de Visualforce, API, Apex por lotes y gestores 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. Exploramos algunas directrices para la redacción de lógica de negocio más adelante, pero por ahora, considere las siguientes instancias para el uso de SOC en Force.com.

• 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. ¿Es el uso de sus métodos de acción en sus controladores de Visualforce 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 métodos de acción complejos en sus controladores de componente Lightning o Visualforce: ¿Alguno de sus códigos lidia con más que la simple gestión de información para y desde el 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