{}const=>[]async()letfn</>var
開発1C

1Cのクリーンアーキテクチャ:それは可能ですか?どのように構築しますか?

1C で他の誰かのコードを開いて、何がどこで起こっているのか理解できませんか?すべてのロジックがフォームに広がり、1 つのモジュールが 2000 行になり、すべての変更がクエストに変わりますか?整理整頓の時です!古典的なアーキテクチャのアプローチが好きではないプラットフォームの条件下でも、コードを読みやすく、変更しやすく、維持しやすくするために、1Cでクリーンアーキテクチャの原則を適用する方法を理解します。

К

Kodik

著者

2分で読める

シンプルな言葉で言うクリーンアーキテクチャとは?

クリーンアーキテクチャは、アプリケーションのビジネスロジックが実装の詳細に依存しないコード編成へのアプローチです。家を建てていると想像してみてください。基礎と支持構造(ビジネスロジック)は、どの壁紙を選ぶか、またはどのタイルを浴室に置くか(インターフェース、データベース)とは無関係である必要があります。

クリーンアーキテクチャの基本原則:

責任の分担 — 各モジュールは独自のタスクを担当します。ドキュメントモジュールはフォームの描画に関与してはなりません。

フレームワークからの独立性 — ビジネスロジックは、1Cプラットフォームにしっかりと結び付けられるべきではありません。

テスト可能性 — システム全体を起動せずにコードを確認できます。

依存関係の方向 — 内部レイヤーは外部レイヤーの存在を認識していません。ビジネスルールは、データがデータベースにどのように保存されているかに依存しません。

🔥 10万人以上の学生が参加中

理論を読むのに疲れた?
コーディングの時間だ!

Kodik — 実践でプログラミングを学ぶアプリ。AIメンター、インタラクティブなレッスン、実際のプロジェクト。

🤖 AI 24時間
🎓 修了証
💰 無料
🚀 始める
今日参加

1Cプラットフォームの特徴

クリーンアーキテクチャについて話す前に、1Cの特性を理解する必要があります。これは単なるプログラミング言語ではなく、独自のゲームルールを持つプラットフォーム全体です。

組み込み言語とメタデータ 密接に関連しています。構成とは別にコードを書くことはできません。すべてがプラットフォーム内に存在します。

オブジェクトモデル 特定の構造を課します。ドキュメント、参照、レジスタは単なるクラスではなく、組み込みの動作を持つオブジェクトです。

トランザクションモデル 独自の法則に従って動作します。通常のアプリケーションのように、データベースの動作を完全に制御することはできません。

フォームとインターフェース コードをゼロから書くのではなく、コンフィギュレーターを介して作成されます。

純粋なアーキテクチャは不可能のように聞こえますか?実際にはそうではなく、適応したアプローチが必要です。

1Cでクリーンアーキテクチャは可能ですか?

簡単に言うと、従来の形式ではできませんが、それに近いものを作成することは可能で、非常に便利です。

1Cはプラットフォームから完全に独立することはできません。ビジネスロジックを Python や Java に移行することはできません。しかし、コードを整理して、理解しやすく、サポートされ、特定の実装から比較的独立したものにすることはできます。

主な目的 — 教科書の理想的なクリーンアーキテクチャを達成するのではなく、理解しやすく変更しやすいコードを書くこと。これは理論的な純粋さよりもはるかに重要です。

1Cのコンテキストにおけるアーキテクチャのレイヤー

典型的な1C構成でレイヤーをどのように区別できるかを見てみましょう。

プレゼンテーションレイヤー

これらはフォーム、コマンド、レポートです。ユーザーが操作するすべてのものです。このレイヤーには最小限のロジックがあり、インターフェースのみが動作します。

❌悪い例:

// ドキュメントフォームモジュール
Процедура ПровестиНаСервере()
    // すぐにデータベースに書き込み、計算し、チェックします
    Запрос = Новый Запрос;
    Запрос.Текст = "SELECT...";
    // 計算を含む50行のコード
    Объект.Записать();
КонецПроцедуры

✅ 良い例:

// フォームモジュール
Процедура ПровестиНаСервере()
    МодульДокументов.ПровестиДокумент(Объект);
КонецПроцедуры

ビジネスロジック層

ここにはあなたのビジネスのルールが存在します。割引の計算方法、書類の発行時期、実行する必要のあるチェック。

1Cでは、これは通常、サーバーコンテキストを持つ一般的なモジュールです。良いトーンは、価格の操作、残高の操作、給与計算など、ドメインごとに分割することです。

// 一般モジュール:価格の操作
Функция РассчитатьИтоговуюЦену(Номенклатура, Количество, Контрагент) Экспорт
    БазоваяЦена = ПолучитьБазовуюЦену(Номенклатура);
    Скидка = РассчитатьСкидку(Контрагент, Количество);
    Возврат БазоваяЦена * Количество * (1 - Скидка / 100);
КонецФункции

Функция РассчитатьСкидку(Контрагент, Количество)
    // ここでは計算のロジックのみ
    Если Количество > 100 Тогда
        Возврат 15;
    ИначеЕсли Контрагент.VIP Тогда
        Возврат 10;
    КонецЕсли;
    Возврат 0;
КонецФункции

注意事項: 関数は、データがどこから来て、どこに書き込まれるのかを知りません。計算を実行するだけです。

データアクセスレイヤー

このレイヤーは、データベースの操作をカプセル化します。すべてのクエリ、オブジェクトの読み取りと書き込みはここにある必要があります。

// 一般モジュール:品目カテゴリーリポジトリ
Функция ПолучитьБазовуюЦену(Номенклатура) Экспорт
    Запрос = Новый Запрос;
    Запрос.Текст = 
    "SELECT
    |    NomenclaturePrices.Price
    |FROM
    | RegisterInformation.PricesNomenclature AS PricesNomenclature
    |WHERE
    |    NomenclaturePrices.Nomenclature = &Nomenclature";
    
    Запрос.УстановитьПараметр("Nomenclature", Номенклатура);
    Выборка = Запрос.Выполнить().Выбрать();
    
    Если Выборка.Следующий() Тогда
        Возврат Выборка.Цена;
    КонецЕсли;
    
    Возврат 0;
КонецФункции

これで、価格の保存構造が変更された場合、このモジュールのみを修正する必要があります。

アーキテクチャを改善するための実践的なテクニック

オブジェクト内のコードの代わりに共通モジュール

ドキュメントとリファレンスのモジュールにすべてのロジックを書かないでください。それを一般的なモジュールに持ち出します。

以下の代わりに:

// 商品の実装ドキュメントモジュール
Процедура ОбработкаПроведения()
    // 200 行のロジック
КонецПроцедуры

やるべきこと:

// ドキュメントモジュール
Процедура ОбработкаПроведения()
    МодульРеализации.Провести(ЭтотОбъект);
КонецПроцедуры

// 一般モジュール:実装モジュール
Процедура Провести(Документ) Экспорт
    // 実施のロジック
КонецПроцедуры

グローバルコンテキストの代わりにパラメータを使用する

グローバル変数に手を出すのではなく、関数のパラメータを介して明示的にデータを渡してください。

悪い点:

Функция РассчитатьСумму()
    // 不明な場所からデータを取得します
    Возврат Объект.Цена * Объект.Количество;
КонецФункции

良い:

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

読み取りと書き込みを分ける

1つのモジュールがデータを読み取り、別のモジュールがデータを処理し、3番目のモジュールがデータを書き込みます。これにより、コードのテストと理解が容易になります。

フォームのロジックを最小限に抑える

フォームはデータを表示し、ユーザーのアクションに応答するだけでなければなりません。すべての処理はサーバーモジュールに移動します。

複雑な操作のためのファサードを作成する

操作に多くのステップが含まれる場合は、単一のエントリーポイントを作成します。

// 一般モジュール:注文のファサードデザイン
Процедура ОформитьЗаказ(ДанныеЗаказа) Экспорт
    ПроверитьДанные(ДанныеЗаказа);
    Заказ = СоздатьДокументЗаказа(ДанныеЗаказа);
    РезервироватьТовары(Заказ);
    ОтправитьУведомление(Заказ);
    Заказ.Записать();
КонецПроцедуры

よくあるミスとその回避方法

最初のミス:すべてが1つのモジュールにあります。 開発者は、あらゆる機会のための機能がある巨大な一般的なモジュールを作成します。コードを意味で分割します。価格を扱うためのモジュール、残高を扱うためのモジュール。

2つ目のミス:論理がフォーム全体に散らばっている。 同じチェックや計算が10種類のフォームにコピーされます。重複するコードを一般的なモジュールに移動します。

3番目のミス:リクエストがあちこちにある。 コードはどこからでもデータベースに直接アクセスします。データを操作するためのリポジトリを作成します。

4 番目のミスは、細部への依存です。 ビジネスロジックは、フォームの構造やデータベースの特定のフィールドについて知っています。実装の詳細は分離してください。

ミス 5:モジュールテストを無視する。 コードをテストできない場合、アーキテクチャが悪いということです。システム全体とは別にテストできるようにコードを書いてください。

実際のコードのリファクタリングの例

典型的な状況を想像してみましょう。実装ドキュメントの処理。

リファクタリング前:

// 商品の実装ドキュメントモジュール
Процедура ОбработкаПроведения()
    // ここで残高を確認します
    Запрос = Новый Запрос;
    Запрос.Текст = "SELECT Remainders...";
    // 合計を計算します
    ИтоговаяСумма = 0;
    Для Каждого Строка Из ТабличнаяЧасть Цикл
        Строка.Сумма = Строка.Цена * Строка.Количество;
        ИтоговаяСумма = ИтоговаяСумма + Строка.Сумма;
    КонецЦикла;
    // 動きを記録する
    Движения.ТоварыНаСкладах.Записать();
    // 取引先を確認する
    Если НЕ Контрагент.Активен Тогда
        ВызватьИсключение("Counterparty blocked!");
    КонецЕсли;
КонецПроцедуры

リファクタリング後:

// ドキュメントモジュール
Процедура ОбработкаПроведения()
    МодульРеализации.Провести(ЭтотОбъект);
КонецПроцедуры

// 一般モジュール:実装モジュール
Процедура Провести(Документ) Экспорт
    ВалидацияКонтрагентов.Проверить(Документ.Контрагент);
    РасчётСумм.РассчитатьСуммыДокумента(Документ);
    РепозиторийОстатков.ПроверитьНаличиеТоваров(Документ.Товары);
    ДвиженияДокументов.СформироватьДвижения(Документ);
КонецПроцедуры

これで、ロジックの各部分がそれぞれのモジュールに収まり、コードを読みやすく、テストしやすくなります。

品質管理ツール

1C用SonarQube コード内の問題(重複、複雑な関数、標準違反)を見つけるのに役立ちます。

EDT (Eclipse Development Tools) 標準のコンフィギュレーターよりも高度な開発機能を提供します。

Vanessa Automation システムの動作を確認するための自動テストを書くことができます。

開発基準 1Cとコミュニティは、チーム内で統一されたコードスタイルを維持するのに役立ちます。

クリーンアーキテクチャを適用するタイミング

すべてのプロジェクトが完璧なアーキテクチャを必要とするわけではありません。1回限りのデータアップロードのために簡単な処理を行う場合は、複雑なモジュール構造を構築する必要はありません。

プロジェクトが長く続き、成長し、開発チームがコードに取り組み、要件が頻繁に変更され、高い信頼性とテスト可能性が必要な場合、クリーンアーキテクチャは意味があります。

小規模な構成や簡単な改良には、基本的な原則で十分です。つまり、モジュールへの分割、重複のない、わかりやすい名前です。

結論

プラットフォームの特性により、クラシックな形での1Cでのクリーンアーキテクチャは不可能です。しかし、クリーンアーキテクチャの原則を適用することで、コードがより明確で信頼性が高く、メンテナンスが容易になります。

小さなことから始めましょう。ロジックをフォームから一般的なモジュールに移動し、コードを責任によって分割し、わかりやすい名前で小さな関数を書きます。すぐに理想を目指すのではなく、プロジェクトの成長に合わせてアーキテクチャを徐々に改善してください。

覚えておいてください: アーキテクチャの目的は、美しい図ではなく、コードを理解しやすく変更しやすくすることです。コードがこの問題を解決する場合は、正しい方向に進んでいます。

1Cのアーキテクチャの基礎、設計パターン、およびベストプラクティスの開発を学ぶことができます コディケ — プログラミング学習のためのプラットフォーム。実際の実践例を用いて、複雑なテーマをシンプルな言葉で解説します。

そして、私たちは素晴らしい テレグラムチャンネル 質問をしたり、経験を共有したり、志を同じくする人を見つけることができるフレンドリーな開発者コミュニティ。
参加してください!

🎯先延ばしをやめよう

記事は気に入った?
実践の時間だ!

Kodikでは読むだけでなく、すぐにコードを書く。理論 + 実践 = 本当のスキル。

即座に実践
🧠AIがコードを説明
🏆修了証

登録不要 • カード不要