安全性、核物理学、愛について：フロントエンドソリューションの最新のITアーキテクチャの矛盾について

依存関係ゲームを直接体験することで 、アプリケーションアーキテクチャの最小の無限集合を理解し続けます。

より多くの電気テープ！

私には友人がいます。彼の職業は電気設備に関連しています。 彼がより若くて冷笑的だったとき、彼は無力なネットワークで働いていた電気技師についての話を毒するのが好きでした。 終わりはいつも楽しかったが、主人公にとっては悲しかった。 コンポーネントアーキテクチャについても同じです。ある機能を別の機能から分離せずに、自分と自分の後に来る人を「ショック」させます。 違いは、ITの分離は、電気の分離よりも依然として高価であることです。









前の記事で、 Sberbankの新しいソリューションである統合フロンタルシステムの機能範囲の最初の工学的推定をすでに行いました。 機能の量の定量的推定、その生産と開発の方法に焦点を当てました。 その接続性と機能を分離する方法について話します。



まず、システムを分離し、適用し、機能を統合しました。 実際、これらは異なる「電圧」と動作条件を持つ異なる「電気回路」です。 その結果、次の図に示すように、有効な依存関係のメタモデルが作成されました。







当然、Sberbankの規模では、適用される機能が支配的です。 したがって、私たちは彼について個別に話します。



フロントエンドバンキングシステムの「非線形電気回路」の類似物は、フロントエンドの顧客サービスシナリオです。 チェーンと同様に、フロントエンドスクリプトは分岐でき、多くのサブプロセスを含めることができます。 すでに「エネルギーの遮断されたネットワーク」に取り組んでいるすべてのアーキテクトの自然な欲求は、プロセスを可能な限り細分化したいという欲求であり、その結果、変更は退行を少なくします。



Unified Frontal Systemの「線形電気回路」の類似物は、フロントエンドシナリオから呼び出されるステートレスロジックです。 シナリオ自体とは異なり、独自のライフサイクルがあります。 Sberbankでは、バックオフィスおよびミドルオフィスバンキング機能用の有望な自動化プラットフォームに基づいて、レガシー機能をソリューションに置き換えるという一般的なプログラムに従属しています。



類推を続けると、個々の電気回路を電気テープで包み、「モジュール」という概念を導入しました。これは、内部で緊密に接続され、別の機能に緩やかに接続される適用機能のグループです。 コードに実装されると、これは通常のjarファイルとpomアーティファクトになります。

適用された機能を細分化するために、統一された少数のルールに限定しようとしましたが、まだ多くの電気テープが必要でした。 サーバー側では、モジュールのターゲット数は10以上です。 これらは規則です：

• ステートレスロジックとステートフルロジックを異なるモジュールに分離。
  
  
• 異なるドメインのエンティティ上のロジックを異なるモジュールに分離。
  
  
• パブリックAPIを個別のモジュールに削除。
  
  
• 製品固有およびチャネル固有のロジックを異なるモジュールに分離。
  
  
• 依存関係の集中のためのモジュールの割り当て。
  
  

互いに分離された適用機能のモジュラー集中の次のメタモデルが得られました：







粒度の制限は、APIモジュールの安定性（サービスAPIとAPIが個別のサブプロセスを呼び出す）によって決まります。

• 規制当局の要件の変更および自動化の対象機能の顧客による提示。
  
  
• ESFがステートレスロジックを委任するシステムまたは統合機能の変更。
  
  
• ステートフル処理チェーンのシーケンスを変更します。
  
  

単一モジュールのサイズは20〜50のJavaクラスです。



これまでのところ、変更されたモジュールは5分の1未満であり、この傾向は今後も続きます。 したがって、建築上の安全上の注意事項に準拠するには、モジュール自体に電気テープを直接追加する必要があります。 ブリッジ、アダプター、ファサードなどのパターンを既に考えているのは良いことです。 これらはすべて、モジュール内部の自然な電気テープになっています。



最も一般的なアプリケーションモジュールの一般的な一般的なアーキテクチャを次の図に示します。 当然、重要なのはそこで何が起こっているかではなく、互いにどのように隔離されているかです。







機能的グラニュレーションの性質により、実行フローの観点から、個々のモジュールのアーキテクチャは、階層化されたアーキテクチャと最も一貫しています。 依存関係により、アプリケーションモジュールのグループ全体を含む最終的なアプリケーションの観点から見ると、プロセス駆動型アーキテクチャです。



上記の利点に加えて、粒状化と豊富な分離には、次のものもあります。

• インタラクションのすべての形式は標準的なものによく分割されており、参加者には抽象化またはマーカーインターフェイスのいずれかを使用できます。
  
  
  
  
• 複数の独立した開発チームが同じモジュールを数か月間編集することができ、なんとなく奇跡的に機能し続けます。
  
  
  
  
• ブリッジ、アダプター、およびファサードは、「未熟」または「熟成」コードの1つまたは別の段階で現れる「割れ目」の集中に適した場所です。
  
  
  
  
• アーキテクチャ違反の簡単なトップレベル制御。 pomファイルを見て、実際の依存関係と設計の依存関係を比較するだけで十分です。
  
  
  
  
• システムの機能は常に不足しているため、初期のプロトタイプは個々のアプリケーションモジュールのレベルで簡単に隔離され、結果として生じる過剰な接続は「拡散」、「コード中毒」しません。
  
  

重大な欠点の中には：

• 高い粒度を維持するための高度な複雑さ。 実際、ブリッジ、アダプター、ファサード、1つのデータ構造を別のデータ構造に転送するための膨大な量のコードには実装が必要です。
  
  
  
  
• ソリューション全体をjar hellに浸さないように、バージョン管理および影響分析機能を開発しておく必要があります。
  
  
  
  
• エンドツーエンドのクロスモジュラーコードの変更には、関連するモジュールグループのブランチからブランチへの同期切り替えが必要であり、モジュール間の依存関係を考慮してプルリクエストを受け入れる必要があります。
  
  

マイクロサービスモノリシック二元論

新入生のための物理学でよく知られている実験室の仕事の中で、同時に粒子（微粒子）と波の両方として振る舞う光子の実験があります。 これらの実験は、波動粒子の双対性の家庭レベルで理解できない特性を説明するために使用されます。 Sberbank United Front Systemの動作は非常に似ています。



ESFには2つの要件があり、それぞれがそれ自体は無害です。

• 「身体的要件」：アプリケーション機能の変更は、他のチャネルの同様の機能を含む、隣接の最小の回帰を意味する必要があります。 ESF全体がエンドツーエンドの回帰の対象になることはありません。 さらに、多数のチームが独自に適用された機能を開発しているため、ESFの「法人化」は避けられません。
  
  
  
  
• 「ウェーブ要件」：カスタマーサービスのロジックの変更は、すべてのサービスチャネルですぐに実行する必要があります。 これはまさにタイトル「ユナイテッド・フロンタル・システム」に反映されている主要なアイデアです-各チャネルへの製品の出力のためのチャネル固有のコストを最小限に抑えるため。
  
  

一般に、両方の要件は矛盾しており、建築における「干渉と回折」について考えさせます。 最初の要件はマイクロサービスアーキテクチャで適切に実装され、2番目の要件はモノリシックで実装されます。



問題の解決策は依存関係管理です。 すべてのチャネルを介して製品を導入する要件の観点から、同じ種類の依存関係を持ち、最小限の回帰と透明性を保証するコンクリートを強化する必要があります。 逆も同様です。回帰ボリュームの観点から依存関係のグループを「透明」にし、製品を変更するための具体的な依存関係を持ちます。



これらの要件を満たす依存関係の最初のグループは、ドメイン駆動設計の実践と自動バンキング領域の一般的な理解に基づいて作成できます。 核物理学との類似性を引き出せば、相互作用が禁じられているドメインの基本的な安定粒子を選べば十分です。 各アプリケーションモジュールは特定のドメインに属している必要があります。



以下は、使用するドメインのマップの例です。 特定のドメインに関連するモジュールは、依存関係チェーンの最上位にない限り、別のドメインのモジュールに直接依存しないようにしてください。



個別のドメインには独自の階層構造があります。 個別のサブドメインを区別することができ、その間の直接的な依存関係も禁止されます。







「粒子波」依存関係の2番目のグループは、機能をクロスチャネルとチャネル固有に分割することで作成できます。 最初のグループの機能は製品の機能であり、2番目のグループの機能は補助です。 次に、プレゼンテーションロジック、ユーザー認証、顧客識別などを構築するチャネル固有の方法から製品の機能を分離して、次の図に示すスキームを構築できます。







注意してください：

• チャネルでクライアントと対話するための特別な手順に関する規制当局の要件が変更された場合、コードの変更はすべてのチャネル製品に有効になります。
  
  
  
  
• 製品自体に関するビジネスの理解が変化すると、すべてのチャネルですべての変更が利用可能になります。
  
  

私たちの経験では、最後の図が機能するためには、次の要件に従うことが重要です。

• クライアントと対話する特定の方法から顧客サービスのアプリケーションシナリオを抽象化するには、よく開発されたクロスチャネルシステム機能が必要です。
  
  
  
  
• 究極の機能を分類し、消費者との相互作用を統一する厳格なビジネスアーキテクチャが必要です。
  
  

読者の皆さん、シュレーディンガー方程式を独立して理解するためのすべてが揃っています。 ;）

あなたが愛するなら-手放す

それでは、モジュールの数で何をしますか？ modules> = 10 ⁴のターゲット形式で思い出させてください。 さらに、顧客は、すべての機能を1四半期に1回以上交換できることを期待しています。



典型的なアプリケーション機能の基本設計パターンは20ダース未満であるという事実にもかかわらず、自動化された操作ごとに次のことを行う必要があります。

• モジュールの機能分解。
  
  
• アプリケーションごとのモジュールのレイアウト。
  
  
• ビジネスエンティティとAPIの設計。
  
  
• モジュール内の依存関係と分離を修正します。
  
  

いくつかのアーキテクチャソリューションを活用します。 コードの再利用のために定められた要件には、アプリケーションモジュールの内容に関する知識が必要であるという事実により、すべてが複雑になっています。

実践により、適用された機能のコンポーネント構造を設計する1人のアーキテクトが〜100モジュールの内容を記憶できることが示されました。 そのため、適用されたすべての機能を管理するために〜100人のアーキテクトがあれば十分です。 しかし、これはすでに建築家自身がお互いについて知らないほど多くの専門家です。 したがって、この問題には管理上の解決策はありません。



幸いなことに、ガブリエルガルシアマルケスは、この問題に対する「対抗管理」ソリューションを以前に提案していました。これはセクションの見出しで作成されました。 ターゲットスケールに保つことは不可能であるため、現在、適用された機能のアーキテクチャの直接設計を「手放し」ています。



各モジュールについて何も知らず、制御のみに進みます。

• 設計中の新しいモジュールの品質、その量的特性を統計的に成功したソリューションの典型的な値と比較します。
  
  
  
  
• リバースエンジニアリングによってコードに加えられた変更の性質。
  
  
  
  
• また、再利用するモジュールの検索を自動化するコンテンツを提供します。
  
  

ここで重要なのは、ITアーキテクチャを多数（特に、多数の典型的なコンポーネント）に減らすことは、十分に多数の特殊なケースで共通のソリューションを実行できるという点で優れたソリューションであるということです。



イベントのクロニクル：

• すべては20のアプリケーションモジュールで始まりました。
  
  
  
  
• 50個のモジュールがある場合、アプリケーションモジュールのターゲット数の推定値が取得され、予備の依存関係メタモデルが構築されました。
  
  
  
  
• モジュール式コンポーネントアーキテクチャを安定させ、アプリケーションモジュールの「生産」の自動化の問題を提起するには、100個のモジュールで十分でした。
  
  
  
  
• 300モジュールは、理想的で許容可能な品質のアプリケーションモジュールの「黄金比」を定量化するのに十分なものになりました。
  
  

現在、機能構成でアプリケーションモジュールの内部設計を実行できる中間ソリューションである多くのプロジェクトに取り組んでいます。これについては、以前の出版物でツールについて説明しました。 アーキテクトは1つの問題のみを手動で解決します。異なるアプリケーションモジュールによる生成のための機能を「レイアウト」し、依存関係に従ってモジュールを最終的な階層に配置します。



応用アーキテクチャを形成するこれらの新しい方法は、何らかの形でスマートとも呼ばれるでしょう。 たとえば、統計駆動型のアプリケーションアーキテクチャ。 どうですか？ ;）



技術的には、適用された設計のプロセスを完全に自動化する準備ができています。 また、GabrielGarcíaMárquezとは異なり、リバースエンジニアリングとは何かを知っていることが重要です。これにより、お気に入りのアプリケーションアーキテクチャをひもにつなぎ、自動生成されたコードの手動完了を制御できるようになります。 しかし、これはすでにダリア・ドンツォワのものです。



結論として、私は次のことに注意します。 すべてのクリエーター（ガルシアマルケスとドンツォバの両方）は、子孫によってのみ真に評価されるという一般的な信念があります。 IT、特にESFでは、そうではありません。 新しいアイデアと技術的ソリューションを検討する準備ができています。 技術コンペティション「プロモーション」に参加してください！