Saubere Architektur in 1C: Ist das möglich und wie baut man sie auf?

Was ist reine Architektur in einfachen Worten?

Clean Architecture ist ein Ansatz zur Codeorganisation, bei dem die Geschäftslogik Ihrer Anwendung unabhängig von den Implementierungsdetails ist. Stellen Sie sich vor, Sie bauen ein Haus: Das Fundament und die tragende Struktur (Geschäftslogik) sollten unabhängig davon sein, welche Tapete Sie wählen oder welche Fliesen Sie im Badezimmer verlegen (Benutzeroberfläche, Datenbank).

Grundprinzipien der Clean Architecture:

Aufteilung der Verantwortlichkeiten - Jedes Modul ist für seine eigene Aufgabe verantwortlich. Das Dokumentenmodul sollte sich nicht mit dem Zeichnen von Formularen befassen.

Unabhängigkeit vom Framework - Die Geschäftslogik sollte nicht fest mit der 1C-Plattform verbunden sein.

Testbarkeit - Der Code kann überprüft werden, ohne das gesamte System zu starten.

Richtung der Abhängigkeiten — Die inneren Schichten sind sich der Existenz der äußeren Schichten nicht bewusst. Geschäftsregeln sind unabhängig davon, wie Daten in der Datenbank gespeichert werden.

Funktionen der 1C-Plattform

Bevor wir über reine Architektur sprechen, müssen wir die Besonderheiten von 1C verstehen. Es ist nicht nur eine Programmiersprache, sondern eine ganze Plattform mit eigenen Spielregeln.

Eingebettete Sprache und Metadaten sind eng miteinander verbunden. Man kann nicht einfach Code getrennt von der Konfiguration schreiben – alles lebt innerhalb der Plattform.

Objektmodell legt eine bestimmte Struktur fest. Dokumente, Verzeichnisse, Register sind nicht nur Klassen, sondern Objekte mit integriertem Verhalten.

Transaktionsmodell arbeitet nach eigenen Gesetzen. Sie können die Arbeit mit der Datenbank nicht wie in normalen Anwendungen vollständig kontrollieren.

Formulare und Benutzeroberfläche werden über den Konfigurator erstellt und nicht mit Code von Grund auf neu geschrieben.

Klingt so, als wäre reine Architektur unmöglich? Eigentlich nicht, man braucht nur einen angepassten Ansatz.

Ist reine Architektur in 1C möglich?

Die kurze Antwort: In der klassischen Form - nein, aber man kann etwas Ähnliches und sehr Nützliches schaffen.

1C gibt Ihnen keine vollständige Unabhängigkeit von der Plattform. Sie können die Geschäftslogik nicht übernehmen und auf Python oder Java übertragen. Sie können den Code jedoch so organisieren, dass er verständlich, unterstützbar und relativ unabhängig von bestimmten Implementierungen ist.

Hauptziel - nicht die ideale saubere Architektur aus dem Lehrbuch zu erreichen, sondern Code zu schreiben, der leicht zu verstehen und zu ändern ist. Dies ist viel wichtiger als theoretische Reinheit.

Architekturschichten im Kontext von 1C

Lassen Sie uns herausfinden, wie Sie Ebenen in einer typischen 1C-Konfiguration hervorheben können.

Darstellungsschicht

Dies sind Formulare, Befehle, Berichte — alles, womit der Benutzer interagiert. Diese Ebene enthält nur wenig Logik, sondern nur die Arbeit mit der Schnittstelle.

❌ Schlechtes Beispiel:

// Im Formularmodul des Dokuments
Процедура ПровестиНаСервере()
    // Wir schreiben sofort in die Datenbank, zählen, prüfen
    Запрос = Новый Запрос;
    Запрос.Текст = "SELECT...";
    // 50 Codezeilen mit Berechnungen
    Объект.Записать();
КонецПроцедуры

✅ Ein gutes Beispiel:

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

Geschäftslogikschicht

Hier leben die Regeln Ihres Unternehmens. Wie man einen Rabatt berechnet, wann man ein Dokument buchen kann, welche Prüfungen durchgeführt werden müssen.

In 1C sind dies normalerweise allgemeine Module mit Serverkontext. Es ist ratsam, sie nach Domänen zu unterteilen: Arbeit mit Preisen, Arbeit mit Resten, Gehaltsabrechnung.

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

Функция РассчитатьСкидку(Контрагент, Количество)
    // Hier ist nur die Berechnungslogik
    Если Количество > 100 Тогда
        Возврат 15;
    ИначеЕсли Контрагент.VIP Тогда
        Возврат 10;
    КонецЕсли;
    Возврат 0;
КонецФункции

Bitte beachten Sie: Die Funktion weiß nicht, woher die Daten stammen und wo sie geschrieben werden. Sie führt nur die Berechnung durch.

Datenzugriffsebene

Diese Schicht kapselt die Arbeit mit der Datenbank ein. Alle Abfragen, Lese- und Schreibobjekte müssen hier sein.

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

Wenn sich nun die Struktur der Preisablage ändert, müssen Sie nur dieses Modul korrigieren.

Praktische Techniken zur Verbesserung der Architektur

Allgemeine Module anstelle von Code in Objekten

Schreiben Sie nicht die gesamte Logik in Dokument- und Verzeichnismodule. Bringen Sie sie in die allgemeinen Module.

Anstelle von:

// Dokumentmodul Warenrealisierung
Процедура ОбработкаПроведения()
    // 200 Logikzeilen
КонецПроцедуры

Was Sie tun sollten:

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

// Allgemeines Modul: Implementierungsmodul
Процедура Провести(Документ) Экспорт
    // Logik der Durchführung
КонецПроцедуры

Verwenden Sie Parameter anstelle des globalen Kontexts

Übergeben Sie Daten explizit über Funktionsparameter und greifen Sie nicht auf globale Variablen zu.

Schlecht:

Функция РассчитатьСумму()
    // Wir nehmen Daten von unbekanntem Ursprung
    Возврат Объект.Цена * Объект.Количество;
КонецФункции

Gut:

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

Lesen und Schreiben trennen

Ein Modul liest die Daten, ein anderes verarbeitet sie, ein drittes schreibt sie. Dies vereinfacht das Testen und Verstehen des Codes.

Minimieren Sie die Logik in Formularen

Formulare sollten nur Daten anzeigen und auf Benutzeraktionen reagieren. Führen Sie die gesamte Verarbeitung in den Servermodulen aus.

Erstellen Sie Fassaden für komplexe Operationen

Wenn der Vorgang viele Schritte umfasst, erstellen Sie einen einzigen Einstiegspunkt.

// AllgemeinesModul: FassadeBestellung
Процедура ОформитьЗаказ(ДанныеЗаказа) Экспорт
    ПроверитьДанные(ДанныеЗаказа);
    Заказ = СоздатьДокументЗаказа(ДанныеЗаказа);
    РезервироватьТовары(Заказ);
    ОтправитьУведомление(Заказ);
    Заказ.Записать();
КонецПроцедуры

Typische Fehler und wie man sie vermeidet

Fehler eins: Alles in einem Modul. Der Entwickler erstellt ein riesiges allgemeines Modul, in dem sich Funktionen für alle Lebenslagen befinden. Teilen Sie den Code nach Bedeutung auf: ein Modul für die Arbeit mit Preisen, ein Modul für die Arbeit mit Resten.

Zweiter Fehler: Die Logik ist über die Formulare verteilt. Ein und dieselbe Prüfung oder Berechnung wird in ein Dutzend Formulare kopiert. Übertragen Sie den sich wiederholenden Code in allgemeine Module.

Fehler Nummer drei: Anfragen überall. Der Code greift von überall direkt auf die Datenbank zu. Erstellen Sie Repositories für die Arbeit mit Daten.

Fehler Nummer vier: Abhängigkeit von Details. Die Geschäftslogik kennt die Struktur von Formularen oder bestimmte Datenbankfelder. Isolieren Sie die Implementierungsdetails.

Fünfter Fehler: Modultests ignorieren. Wenn der Code nicht getestet werden kann, ist die Architektur schlecht. Schreiben Sie den Code so, dass er getrennt vom gesamten System getestet werden kann.

Beispiel für das Refactoring von echtem Code

Stellen Sie sich eine typische Situation vor: die Bearbeitung eines Verkaufsbelegs.

Vor dem Refactoring:

// Dokumentmodul Warenrealisierung
Процедура ОбработкаПроведения()
    // Wir überprüfen die Restbeträge direkt hier
    Запрос = Новый Запрос;
    Запрос.Текст = "SELECT Remainders...";
    // Wir berechnen die Beträge
    ИтоговаяСумма = 0;
    Для Каждого Строка Из ТабличнаяЧасть Цикл
        Строка.Сумма = Строка.Цена * Строка.Количество;
        ИтоговаяСумма = ИтоговаяСумма + Строка.Сумма;
    КонецЦикла;
    // Wir zeichnen Bewegungen auf
    Движения.ТоварыНаСкладах.Записать();
    // Wir überprüfen den Geschäftspartner
    Если НЕ Контрагент.Активен Тогда
        ВызватьИсключение("Counterparty blocked!");
    КонецЕсли;
КонецПроцедуры

Nach dem Refactoring:

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

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

Jetzt lebt jeder Teil der Logik in seinem eigenen Modul, der Code ist einfach zu lesen und zu testen.

Tools zur Qualitätskontrolle

SonarQube für 1C hilft, Probleme im Code zu finden: Duplikate, komplexe Funktionen, Verstöße gegen Standards.

EDT (Eclipse Development Tools) bietet erweiterte Entwicklungsmöglichkeiten im Vergleich zum Standardkonfigurator.

Vanessa Automation ermöglicht das Schreiben automatischer Tests, um das Verhalten des Systems zu überprüfen.

Entwicklungsstandards von 1C und der Community helfen, einen einheitlichen Codestil im Team aufrechtzuerhalten.

Wann man eine reine Architektur verwenden sollte

Nicht jedes Projekt braucht eine perfekte Architektur. Wenn Sie eine einfache Verarbeitung für einen einmaligen Datenexport durchführen, sollten Sie keine komplexe Struktur von Modulen erstellen.

Reine Architektur ist sinnvoll, wenn: das Projekt lange lebt und wächst, ein Entwicklungsteam am Code arbeitet, sich die Anforderungen häufig ändern, hohe Zuverlässigkeit und Testbarkeit erforderlich sind.

Für kleine Konfigurationen und einfache Verbesserungen genügen grundlegende Prinzipien: Aufteilung in Module, keine Duplikate, verständliche Namen.

Schlussfolgerungen

Eine reine Architektur in 1C in klassischer Form ist aufgrund der Besonderheiten der Plattform nicht möglich. Die Anwendung der Prinzipien der sauberen Architektur macht den Code jedoch klarer, zuverlässiger und einfacher zu warten.

Fangen Sie klein an: Verlagern Sie die Logik aus Formularen in allgemeine Module, teilen Sie den Code nach Verantwortlichkeit auf, schreiben Sie kleine Funktionen mit klaren Namen. Streben Sie nicht sofort nach Perfektion – verbessern Sie die Architektur schrittweise, während das Projekt wächst.

Denken Sie daran: Der Zweck der Architektur liegt nicht in schönen Diagrammen, sondern darin, den Code leicht verständlich und änderbar zu machen. Wenn Ihr Code dieses Problem löst, sind Sie auf dem richtigen Weg.

Sie können die Grundlagen der Architektur, Entwurfsmuster und bewährte Entwicklungspraktiken in 1C lernen in Kodike — unsere Plattform für den Programmierunterricht. Wir erklären komplexe Themen in einfacher Sprache, mit Beispielen aus der Praxis.

Und wir haben auch einen coolen Telegram-Kanal mit einer freundlichen Entwickler-Community, in der Sie Fragen stellen, Erfahrungen teilen und Gleichgesinnte finden können.
Machen Sie mit!