Arquitectura limpia en 1C: ¿es posible y cómo construirla?

¿Qué es la arquitectura limpia en palabras sencillas?

La arquitectura limpia es un enfoque para organizar el código en el que la lógica empresarial de tu aplicación no depende de los detalles de la implementación. Imagina que estás construyendo una casa: los cimientos y las estructuras de soporte (lógica empresarial) deben ser independientes del papel pintado que elijas o de las baldosas que coloques en el baño (interfaz, base de datos).

Principios básicos de la arquitectura limpia:

Separación de responsabilidades — cada módulo es responsable de su tarea. El módulo de trabajo con documentos no debe ocuparse del dibujo de formularios.

Independencia del marco — la lógica empresarial no debe estar firmemente ligada a la plataforma 1C.

Capacidad de prueba — el código se puede comprobar sin ejecutar todo el sistema.

Dirección de las dependencias — las capas internas no son conscientes de la existencia de las externas. Las reglas de negocio no dependen de cómo se almacenan los datos en la base de datos.

Características de la plataforma 1C

Antes de hablar de arquitectura limpia, es necesario comprender los detalles de 1C. No es solo un lenguaje de programación, sino toda una plataforma con sus propias reglas de juego.

Idioma y metadatos integrados están estrechamente relacionados entre sí. No puedes simplemente escribir código separado de la configuración: todo vive dentro de la plataforma.

Modelo de objeto impone una cierta estructura. Los documentos, directorios, registros no son solo clases, sino objetos con comportamiento incorporado.

Modelo transaccional funciona según sus propias leyes. No se puede controlar completamente el trabajo con la base de datos, como en las aplicaciones normales.

Formularios e interfaz se crean a través del configurador y no se escriben con código desde cero.

¿Suena como si la arquitectura pura fuera imposible? En realidad no, solo necesitas un enfoque adaptado.

¿Es posible una arquitectura limpia en 1C?

La respuesta corta es: en su forma clásica, no, pero puedes crear algo parecido y muy útil.

1C no le dará una independencia completa de la plataforma. No podrá tomar la lógica empresarial y transferirla a Python o Java. Pero puedes organizar el código para que sea comprensible, compatible y relativamente independiente de las implementaciones específicas.

Objetivo principal - no lograr una arquitectura limpia ideal de un libro de texto, sino escribir un código que sea fácil de entender y cambiar. Esto es mucho más importante que la pureza teórica.

Capas de arquitectura en el contexto de 1C

Veamos cómo se pueden resaltar las capas en una configuración típica de 1C.

Capa de presentación

Estos son formularios, comandos, informes, todo con lo que interactúa el usuario. Esta capa tiene un mínimo de lógica, solo trabaja con la interfaz.

❌ Mal ejemplo:

// En el módulo de formulario de documento
Процедура ПровестиНаСервере()
    // Inmediatamente escribimos en la base, contamos, comprobamos
    Запрос = Новый Запрос;
    Запрос.Текст = "SELECT...";
    // 50 líneas de código con cálculos
    Объект.Записать();
КонецПроцедуры

✅ Buen ejemplo:

// En el módulo de formularios
Процедура ПровестиНаСервере()
    МодульДокументов.ПровестиДокумент(Объект);
КонецПроцедуры

Capa de lógica empresarial

Aquí viven las reglas de tu negocio. Cómo calcular un descuento, cuándo se puede publicar un documento, qué comprobaciones se deben realizar.

En 1C, estos suelen ser módulos comunes con un contexto de servidor. Es una buena idea dividirlos por dominios: trabajo con precios, trabajo con saldos, cálculo de salarios.

// Módulo general: Trabajo con precios
Функция РассчитатьИтоговуюЦену(Номенклатура, Количество, Контрагент) Экспорт
    БазоваяЦена = ПолучитьБазовуюЦену(Номенклатура);
    Скидка = РассчитатьСкидку(Контрагент, Количество);
    Возврат БазоваяЦена * Количество * (1 - Скидка / 100);
КонецФункции

Функция РассчитатьСкидку(Контрагент, Количество)
    // Aquí solo se muestra la lógica del cálculo
    Если Количество > 100 Тогда
        Возврат 15;
    ИначеЕсли Контрагент.VIP Тогда
        Возврат 10;
    КонецЕсли;
    Возврат 0;
КонецФункции

Tenga en cuenta: la función no sabe de dónde provienen los datos ni dónde se escriben. Simplemente hace el cálculo.

Capa de acceso a datos

Esta capa encapsula el trabajo con la base de datos. Todas las consultas, lectura y escritura de objetos deben estar aquí.

// Módulo general: Repositorio de nomenclaturas
Функция ПолучитьБазовуюЦену(Номенклатура) Экспорт
    Запрос = Новый Запрос;
    Запрос.Текст = 
    "SELECT
    |    NomenclaturePrices.Price
    |FROM
    | RegisterInformation.PricesNomenclature AS PricesNomenclature
    |WHERE
    |    NomenclaturePrices.Nomenclature = &Nomenclature";
    
    Запрос.УстановитьПараметр("Nomenclature", Номенклатура);
    Выборка = Запрос.Выполнить().Выбрать();
    
    Если Выборка.Следующий() Тогда
        Возврат Выборка.Цена;
    КонецЕсли;
    
    Возврат 0;
КонецФункции

Ahora, si cambia la estructura de almacenamiento de precios, solo tendrá que corregir este módulo.

Técnicas prácticas para mejorar la arquitectura

Módulos comunes en lugar de código en objetos

No escriba toda la lógica en los módulos de documentos y directorios. Llévala a los módulos generales.

En lugar de:

// Módulo de documento de venta de productos
Процедура ОбработкаПроведения()
    // 200 líneas de lógica
КонецПроцедуры

Haz:

// Módulo de documento
Процедура ОбработкаПроведения()
    МодульРеализации.Провести(ЭтотОбъект);
КонецПроцедуры

// Módulo general: Módulo de implementación
Процедура Провести(Документ) Экспорт
    // Lógica de la realización
КонецПроцедуры

Utilice los parámetros en lugar del contexto global

Transmite los datos explícitamente a través de los parámetros de las funciones, no recurras a las variables globales.

Mal:

Функция РассчитатьСумму()
    // Tomamos datos de un lugar desconocido
    Возврат Объект.Цена * Объект.Количество;
КонецФункции

Bien:

Функция РассчитатьСумму(Цена, Количество)
    Возврат Цена * Количество;
КонецФункции

Separar la lectura y la escritura

Un módulo lee los datos, otro los procesa y el tercero los escribe. Esto facilita las pruebas y la comprensión del código.

Minimiza la lógica en los formularios

Los formularios solo deben mostrar datos y responder a las acciones del usuario. Todo el procesamiento se lleva a cabo en los módulos del servidor.

Crea fachadas para operaciones complejas

Si la operación incluye muchos pasos, cree un único punto de entrada.

// Módulo general: Diseño de la fachada del pedido
Процедура ОформитьЗаказ(ДанныеЗаказа) Экспорт
    ПроверитьДанные(ДанныеЗаказа);
    Заказ = СоздатьДокументЗаказа(ДанныеЗаказа);
    РезервироватьТовары(Заказ);
    ОтправитьУведомление(Заказ);
    Заказ.Записать();
КонецПроцедуры

Errores típicos y cómo evitarlos

Primer error: todo en un solo módulo. El desarrollador crea un enorme módulo común, donde se encuentran las funciones para todas las ocasiones. Divide el código por significado: un módulo para trabajar con precios, un módulo para trabajar con saldos.

Segundo error: la lógica está esparcida por los formularios. La misma comprobación o cálculo se copia en una docena de formularios. Mueva el código duplicado a los módulos comunes.

Tercer error: consultas por todas partes. El código accede directamente a la base de datos desde cualquier lugar. Crea repositorios para trabajar con datos.

Cuarto error: dependencia de los detalles. La lógica empresarial conoce la estructura de los formularios o los campos específicos de la base de datos. Aísla los detalles de la implementación.

Error cinco: ignorar las pruebas unitarias. Si el código no se puede probar, entonces la arquitectura es mala. Escriba el código de manera que se pueda verificar por separado de todo el sistema.

Ejemplo de refactorización de código real

Imaginemos una situación típica: el procesamiento de un documento de implementación.

Antes de la refactorización:

// Módulo de documento de venta de productos
Процедура ОбработкаПроведения()
    // Comprobamos los saldos aquí mismo
    Запрос = Новый Запрос;
    Запрос.Текст = "SELECT Remainders...";
    // Contamos las cantidades
    ИтоговаяСумма = 0;
    Для Каждого Строка Из ТабличнаяЧасть Цикл
        Строка.Сумма = Строка.Цена * Строка.Количество;
        ИтоговаяСумма = ИтоговаяСумма + Строка.Сумма;
    КонецЦикла;
    // Registramos los movimientos
    Движения.ТоварыНаСкладах.Записать();
    // Verificamos a la contraparte
    Если НЕ Контрагент.Активен Тогда
        ВызватьИсключение("Counterparty blocked!");
    КонецЕсли;
КонецПроцедуры

Después de la refactorización:

// Módulo de documento
Процедура ОбработкаПроведения()
    МодульРеализации.Провести(ЭтотОбъект);
КонецПроцедуры

// Módulo general: Módulo de implementación
Процедура Провести(Документ) Экспорт
    ВалидацияКонтрагентов.Проверить(Документ.Контрагент);
    РасчётСумм.РассчитатьСуммыДокумента(Документ);
    РепозиторийОстатков.ПроверитьНаличиеТоваров(Документ.Товары);
    ДвиженияДокументов.СформироватьДвижения(Документ);
КонецПроцедуры

Ahora cada parte de la lógica vive en su propio módulo, el código es fácil de leer y probar.

Herramientas de control de calidad

SonarQube para 1C ayuda a encontrar problemas en el código: duplicación, funciones complejas, violaciones de estándares.

EDT (Eclipse Development Tools) proporciona capacidades de desarrollo más avanzadas en comparación con el configurador estándar.

Vanessa Automation permite escribir pruebas automáticas para comprobar el comportamiento del sistema.

Normas de desarrollo de 1C y la comunidad ayudan a mantener un estilo de código uniforme en el equipo.

Cuándo aplicar la arquitectura limpia

No todos los proyectos necesitan una arquitectura perfecta. Si estás haciendo un procesamiento simple para una descarga de datos única, no construyas una estructura de módulos compleja.

La arquitectura limpia tiene sentido cuando: el proyecto vivirá mucho tiempo y crecerá, un equipo de desarrolladores está trabajando en el código, los requisitos cambian a menudo, se necesita una alta fiabilidad y capacidad de prueba.

Para configuraciones pequeñas y mejoras simples, los principios básicos son suficientes: división en módulos, sin duplicación, nombres claros.

Conclusiones

La arquitectura limpia en 1C en su forma clásica es imposible debido a las características de la plataforma. Pero la aplicación de los principios de la arquitectura limpia hace que el código sea más claro, más fiable y más fácil de mantener.

Empiece poco a poco: saque la lógica de los formularios a los módulos comunes, divida el código por responsabilidad, escriba funciones pequeñas con nombres comprensibles. No busques la perfección de inmediato: mejora la arquitectura gradualmente a medida que crece el proyecto.

Recuerda: el propósito de la arquitectura no es crear diagramas bonitos, sino hacer que el código sea fácil de entender y cambiar. Si tu código resuelve este problema, estás en el camino correcto.

Puedes aprender los conceptos básicos de arquitectura, patrones de diseño y las mejores prácticas de desarrollo en 1C en Codice — nuestra plataforma de aprendizaje de programación. Analizamos temas complejos en un lenguaje sencillo, con ejemplos de la práctica real.

Y también tenemos un genial Canal de Telegram con una comunidad amigable de desarrolladores donde puedes hacer preguntas, compartir experiencias y encontrar personas afines.
¡Únete!