Architecture propre dans 1C : est-ce possible et comment la construire ?

Qu'est-ce que l'architecture pure en termes simples ?

L'architecture propre est une approche de l'organisation du code dans laquelle la logique métier de votre application ne dépend pas des détails de l'implémentation. Imaginez que vous construisez une maison : les fondations et les structures porteuses (logique métier) doivent être indépendantes du papier peint que vous choisissez ou du carrelage que vous posez dans la salle de bain (interface, base de données).

Principes de base de l'architecture propre :

Partage des responsabilités — chaque module est responsable de sa propre tâche. Le module de travail avec les documents ne doit pas être impliqué dans le rendu des formulaires.

Indépendance du framework — la logique métier ne doit pas être fermement liée à la plateforme 1C.

Testabilité — le code peut être vérifié sans démarrer l'ensemble du système.

Direction des dépendances — les couches internes ne sont pas conscientes de l'existence des couches externes. Les règles métier ne dépendent pas de la manière dont les données sont stockées dans la base de données.

Caractéristiques de la plateforme 1C

Avant de parler d'architecture propre, vous devez comprendre les spécificités de 1C. Ce n'est pas seulement un langage de programmation, mais toute une plate-forme avec ses propres règles du jeu.

Langue intégrée et métadonnées sont étroitement liés. Vous ne pouvez pas simplement prendre et écrire du code séparément de la configuration — tout vit à l'intérieur de la plate-forme.

Modèle objet impose une certaine structure. Les documents, les annuaires, les registres ne sont pas seulement des classes, mais des objets avec un comportement intégré.

Modèle transactionnel fonctionne selon ses propres lois. Vous ne pouvez pas contrôler complètement le travail avec la base de données, comme dans les applications ordinaires.

Formulaires et interface sont créés via le configurateur et ne sont pas écrits avec du code à partir de zéro.

On dirait que l'architecture pure est impossible ? En fait, non, il suffit d'adapter l'approche.

Une architecture propre est-elle possible dans 1C ?

La réponse courte : sous la forme classique, non, mais vous pouvez créer quelque chose de proche et de très utile.

1C ne vous donnera pas une indépendance totale de la plateforme. Vous ne pourrez pas prendre la logique métier et la transférer en Python ou Java. Mais vous pouvez organiser le code de manière à ce qu'il soit compréhensible, pris en charge et relativement indépendant des implémentations spécifiques.

Objectif principal — ne pas atteindre l'architecture idéale et pure du manuel, mais écrire un code facile à comprendre et à modifier. C'est beaucoup plus important que la pureté théorique.

Couches d'architecture dans le contexte de 1C

Voyons comment vous pouvez mettre en évidence les couches dans une configuration 1C typique.

Couche de présentation

Il s'agit de formulaires, de commandes, de rapports, de tout ce avec quoi l'utilisateur interagit. Cette couche contient un minimum de logique, elle ne fait que travailler avec l'interface.

❌ Mauvais exemple :

// Dans le module de formulaire de document
Процедура ПровестиНаСервере()
    // Écrire immédiatement dans la base de données, compter, vérifier
    Запрос = Новый Запрос;
    Запрос.Текст = "SELECT...";
    // 50 lignes de code avec calculs
    Объект.Записать();
КонецПроцедуры

✅ Bon exemple :

// Dans le module de formulaire
Процедура ПровестиНаСервере()
    МодульДокументов.ПровестиДокумент(Объект);
КонецПроцедуры

Couche de logique métier

C'est ici que les règles de votre entreprise prennent vie. Comment calculer une remise, quand vous pouvez passer un document, quelles vérifications doivent être effectuées.

Dans 1C, il s'agit généralement de modules communs avec un contexte serveur. Une bonne pratique consiste à les diviser par domaines : travail avec les prix, travail avec les soldes, calcul des salaires.

// Module général : Travail avec les prix
Функция РассчитатьИтоговуюЦену(Номенклатура, Количество, Контрагент) Экспорт
    БазоваяЦена = ПолучитьБазовуюЦену(Номенклатура);
    Скидка = РассчитатьСкидку(Контрагент, Количество);
    Возврат БазоваяЦена * Количество * (1 - Скидка / 100);
КонецФункции

Функция РассчитатьСкидку(Контрагент, Количество)
    // Ici, seule la logique de calcul
    Если Количество > 100 Тогда
        Возврат 15;
    ИначеЕсли Контрагент.VIP Тогда
        Возврат 10;
    КонецЕсли;
    Возврат 0;
КонецФункции

Veuillez noter : la fonction ne sait pas d'où viennent les données et où elles sont écrites. Elle effectue simplement le calcul.

Couche d'accès aux données

Cette couche encapsule le travail avec la base de données. Toutes les requêtes, la lecture et l'écriture des objets doivent être ici.

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

Désormais, si la structure de stockage des prix change, vous n'aurez qu'à corriger ce module.

Techniques pratiques pour améliorer l'architecture

Modules communs au lieu du code dans les objets

N'écrivez pas toute la logique dans les modules de documents et de référence. Placez-la dans les modules généraux.

Au lieu de :

// Module du document Vente de marchandises
Процедура ОбработкаПроведения()
    // 200 lignes de logique
КонецПроцедуры

Faites :

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

// Module général : Module de réalisation
Процедура Провести(Документ) Экспорт
    // Logique de conduite
КонецПроцедуры

Utilisez les paramètres au lieu du contexte global

Transmettez les données explicitement via les paramètres de la fonction, ne vous étendez pas aux variables globales.

Mauvais :

Функция РассчитатьСумму()
    // Nous prenons les données de nulle part
    Возврат Объект.Цена * Объект.Количество;
КонецФункции

Bien :

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

Séparez la lecture et l'écriture

Un module lit les données, un autre les traite, un troisième les écrit. Cela simplifie les tests et la compréhension du code.

Minimisez la logique dans les formulaires

Les formulaires doivent uniquement afficher les données et répondre aux actions de l'utilisateur. Effectuez tout le traitement dans les modules du serveur.

Créez des façades pour des opérations complexes

Si l'opération comporte plusieurs étapes, créez un point d'entrée unique.

// Module général : Façade de la commande
Процедура ОформитьЗаказ(ДанныеЗаказа) Экспорт
    ПроверитьДанные(ДанныеЗаказа);
    Заказ = СоздатьДокументЗаказа(ДанныеЗаказа);
    РезервироватьТовары(Заказ);
    ОтправитьУведомление(Заказ);
    Заказ.Записать();
КонецПроцедуры

Erreurs typiques et comment les éviter

Première erreur : tout dans un seul module. Le développeur crée un énorme module commun, où les fonctions pour toutes les occasions se trouvent. Séparez le code par sens : un module pour travailler avec les prix, un module pour travailler avec les restes.

Deuxième erreur : la logique est étalée sur les formulaires. La même vérification ou le même calcul est copié dans une douzaine de formulaires. Déplacez le code en double dans les modules partagés.

Troisième erreur : les requêtes sont partout. Le code accède directement à la base de données depuis n'importe quel endroit. Créez des référentiels pour travailler avec les données.

Quatrième erreur : dépendance aux détails. La logique métier connaît la structure des formulaires ou des champs de base de données spécifiques. Isolez les détails de l'implémentation.

Cinquième erreur : ignorer les tests unitaires. Si le code ne peut pas être testé, alors l'architecture est mauvaise. Écrivez le code de manière à ce qu'il puisse être vérifié séparément de l'ensemble du système.

Exemple de remaniement de code réel

Imaginons une situation typique : le traitement d'un document de mise en œuvre.

Avant le remaniement :

// Module du document Vente de marchandises
Процедура ОбработкаПроведения()
    // Vérifiez les soldes ici
    Запрос = Новый Запрос;
    Запрос.Текст = "SELECT Remainders...";
    // Nous calculons les montants
    ИтоговаяСумма = 0;
    Для Каждого Строка Из ТабличнаяЧасть Цикл
        Строка.Сумма = Строка.Цена * Строка.Количество;
        ИтоговаяСумма = ИтоговаяСумма + Строка.Сумма;
    КонецЦикла;
    // Enregistrer les mouvements
    Движения.ТоварыНаСкладах.Записать();
    // Vérification de la contrepartie
    Если НЕ Контрагент.Активен Тогда
        ВызватьИсключение("Counterparty blocked!");
    КонецЕсли;
КонецПроцедуры

Après le remaniement :

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

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

Maintenant, chaque partie de la logique vit dans son propre module, le code est facile à lire et à tester.

Outils de contrôle de la qualité

SonarQube pour 1C aide à trouver des problèmes dans le code : duplication, fonctions complexes, violations des normes.

EDT (Eclipse Development Tools) offre des capacités de développement plus avancées que le configurateur standard.

Vanessa Automation vous permet d'écrire des tests automatiques pour vérifier le comportement du système.

Normes de développement de 1C et de la communauté aident à maintenir un style de code uniforme dans l'équipe.

Quand faut-il appliquer une architecture propre

Tous les projets n'ont pas besoin d'une architecture parfaite. Si vous effectuez un traitement simple pour un téléchargement de données unique, ne construisez pas une structure de module complexe.

L'architecture propre a du sens lorsque : le projet vivra longtemps et se développera, une équipe de développement travaille sur le code, les exigences changent souvent, une fiabilité et une testabilité élevées sont nécessaires.

Pour les petites configurations et les améliorations simples, les principes de base sont suffisants : division en modules, pas de duplication, noms clairs.

Conclusions

L'architecture propre dans 1C sous sa forme classique est impossible en raison des caractéristiques de la plate-forme. Mais l'application des principes de l'architecture propre rend le code plus clair, plus fiable et plus facile à maintenir.

Commencez petit : déplacez la logique des formulaires vers des modules communs, divisez le code par responsabilité, écrivez de petites fonctions avec des noms clairs. Ne visez pas l'idéal tout de suite : améliorez l'architecture progressivement, au fur et à mesure que le projet se développe.

Rappelez-vous : le but de l'architecture n'est pas de créer de beaux diagrammes, mais de rendre le code facile à comprendre et à modifier. Si votre code résout ce problème, vous êtes sur la bonne voie.

Vous pouvez apprendre les bases de l'architecture, les modèles de conception et les meilleures pratiques de développement en 1C dans Codique — notre plateforme d'apprentissage de la programmation. Nous analysons des sujets complexes dans un langage simple, avec des exemples tirés de la pratique réelle.

Et nous avons aussi un super Chaîne Telegram avec une communauté amicale de développeurs où vous pouvez poser des questions, partager des expériences et trouver des personnes partageant les mêmes idées.
Rejoignez-nous !