システムアーキテクチャの合理性を考える | JD Cloudテクニカルチーム

最近、私が中心になって部門のシステムアーキテクチャの合理性を整理することになったのですが、仕事を始める前にまず考えたのは、アーキテクチャの合理性をどう定義するか？

研究開発の観点から見ると、システムのコンテキストが明確で、アプリケーションのアーキテクチャ設計がシンプルで、アプリケーションの分割が合理的であれば、それは合理的なアーキテクチャと呼ばれるはずです。

上記の定義に基づくと、評価は次の 3 つの観点から整理できます。

1. システムのコンテキストが明確です。周囲のシステムとの呼び出し関係、およびデータ同期メカニズムが明確にわかります。

2. アプリケーションアーキテクチャの設計はシンプルです。アーキテクチャは合理的に階層化されており、機能の位置付けが明確であり、機能の境界の外側にあるものはありません。

3. アプリケーションの合理的な分割: システム内のアプリケーションの粒度は適切な範囲内にあり、アプリケーション間の呼び出しリンクが長すぎてはいけません。

システムのコンテキストが明確である

システムコンテキストダイアグラムという用語は、最初に Simon Brown の C4 モデルから借用されました。このモデルは、「さまざまな抽象レベルでボックスと破線を再定義することによってアーキテクチャの意味を抽象的に表現します」。

C4 モデルはシステムを 4 つのレイヤーに分割し、各レイヤーは異なる懸念事項を持つ異なるビューアーキテクチャを表します。最初の層であるシステムコンテキストは、システムの高レベルの抽象化です。

以下の図は、個人の銀行口座の口座を閲覧するプロセスにおけるさまざまなシステム間の相互作用を示しています。インターネットバンキングシステムを対象システムとすると、電子メールシステムやマリンフレームバンキングシステムは、それに付随するシステムであり、インターネットバンキングシステムにシステム価値を提供するシステムの外側にある外部システムとも言えます。箱。

システムコンテキストは、対象システムと外部システムとの関係を定義し、外部システムとともに対象ユーザーに価値を提供します。システムコンテキストを描画するときは、ターゲットシステムと外部システム間の依存関係の方向に注意する必要があります。ノースバウンド依存関係は、外部システムが対象システムのサービスを呼び出すことを意味し、対象システムがどのようなサービスコントラクトを定義するかを考慮する必要があり、サウスバウンド依存関係は、対象システムが外部システムのサービスを呼び出すことを意味し、対象システムがどのようなサービスコントラクトを定義するかを考慮する必要があります。外部システムのメカニズムのインターフェイス、呼び出し方法、通信、さらには外部システムに障害が発生した場合にターゲットシステムが何をすべきかを理解する。

上記の描画方法を参考にするほか、業務シーケンス図で表現することもできます。UML のシーケンス図から生まれました。シーケンス図は左側の役割から開始でき、メッセージが渡される順序を示します。これは、この種の推進力を意味します。左側の参加オブジェクトから開始して、それらと連携するための実行ステップを探し、その後、完全なコラボレーションプロセス全体を層ごとに推定します。

エンタープライズシーケンス図は、エンタープライズレベルのシステムの抽象化、ターゲットシステムと外部システム間の協力関係を表し、参加するシステムは完全な全体であるため、内部の詳細に参加する必要はなく、参加する必要もありません。システムの実装、メッセージの方向性の方が重要であり、多くはシステムの責任を表します。ビジネスシーケンス図は次のようになります。

シンプルなアプリケーションアーキテクチャ設計

アプリケーション自体は階層化されたアーキテクチャを持っており、Martin Fowler は「Enterprise Application Architecture Patterns」の中で、合理的なシステム層にはプレゼンテーション層、ドメインロジック層、データソース層を含めるべきであると提案しました。プレゼンテーション層は主にサービスを提供し、ユーザーのリクエストを処理します。ドメイン層は処理ロジックであり、システムの中核です。データソース層は、データ層、メッセージシステム、およびその他のソフトウェアパッケージと通信します。

その後のドメイン駆動アーキテクチャ設計の発展は、プレゼンテーション層の下にアプリケーション層を追加し、データソース層をインフラストラクチャ層に変更することで、データベース管理システムの限界を打ち破り、4層に進化しました。

上記のシステム階層化に基づいて、3 層アーキテクチャを採用するか 4 層アーキテクチャを採用するかにかかわらず、アプリケーションは機能境界を表し、これらのコア機能、何ができるか、何ができないかを提供します。

良い実践経験としては、ドメイン駆動設計のビジネスドメインの方法論を参照し、システムの第 1、第 2、および第 3 レベルのドメイン (最大 4 レベルを超えない) を整理し、すべてのレベルでドメインを定義することです。。適切なドメイン定義はシステム機能の境界を表し、何ができて何ができないかを理解できるようにします。

上記で整理したシステム事業領域の定義と能力の境界に基づいて、通常、システムは 2 つのタイプに分類され、1 つは既存のストックシステムと比較的頻繁に需要が繰り返されるシステムです。システムは、コア機能は何か、それらが上記のシステムのドメイン定義内にあるかどうか、他のシステムが同様の機能を持っているかどうか、もしそうであればマージを検討する必要があるかを整理する必要があります。また、システムの車輪が何度も作られることを避けるために、コア機能のオープン性と文書化を考慮し、少なくとも部門に知らせ、チェックする場所を用意することも必要です。

2 番目のタイプのシステムはストックシステムであり、需要の反復がなく、ビジネスでは基本的にコール量がありません。このタイプのシステムは、オフライン計画があるかどうか、置き換え可能な同様のシステムがあるかどうかを企業と通信し、ビジネス上の意思決定に技術的な参照を提供する必要があります。

合理的なアプリ分割

要件開発では、プロジェクトまたは要件を実現するには、複数のターゲットシステムの連携が必要となる場合があり、これにはターゲットシステムの分割の粒度が関係します。システムをアプリケーションに分割する粒度についての統一基準はありませんが、統一する必要があります。考慮する要素としては、事業計画、システムコールの規模、事業計画に基づくアーキテクチャ設計、部門の人数、分業などが考えられます。多すぎても少なすぎてもダメです。

新しいビジネスが短期間で大きな発展を遂げない場合は、最初の申請計画時に大まかに分割することができます。部門内の平均人数は 2 ～ 3 件の申請を超えないようにする必要があります。異なるシステム間での切り替えにはコストがかかります。フォロー業務が発展し、部門の人員が増えた場合、分業が細かくなるため、よりきめ細かい分割が考えられますが、システムを分割すると、システム間の連携をどうするかという別の問題が必然的に発生します。システムコールの長さをリンクする方法。

前述のシステム階層化の概念に基づいて、部門内のシステムは 2 つのタイプに分類できます。1 つはビジネスゲートウェイであり、もう 1 つは一般的なビジネスケイパビリティです。ビジネスゲートウェイはユーザー指向であり、アプリケーションのアクティビティを調整するために使用されます。ビジネスロジックは含まれず、ビジネスオブジェクトの状態も保持されません。ドメイン駆動設計のアプリケーション層 + プレゼンテーション層に相当します。これをビジネス SOA と呼ぶ人もいます。またはBFFレイヤー。

一般的なビジネス機能はドメインロジック層+インフラストラクチャ層に相当し、ソフトウェアの中核としてビジネスオブジェクトの状態を保持し、ビジネスオブジェクトの永続化はインフラストラクチャ層に委ねられます。他の層が実現するためのサポート層他のシステムと通信するために、ビジネスオブジェクトの永続化を実現します。

上記 2 種類のシステムでは、サービスゲートウェイは一般サービス機能層に依存し、サービスゲートウェイはノースバウンドに依存し、一般サービス機能層はサウスバウンドに依存します。機能実装ではリンク長が 2 を超えないようにすることはお勧めできません。同時に、システム間の相互依存にも注意を払う必要があり、この点がシステムの安定性にとってのリスクポイントであることに注意する必要があります。

コストの定量化:

上記 3 つの側面の分析に基づいて、次の成果物が整理されます: 1. システムのコンテキスト依存性; 2. システムのビジネスドメイン定義とキャパシティプランニングマップ。3. アプリケーション呼び出しリンクの長さと相互依存関係、4. アプリケーション分割粒度の合理性の評価、5. システム内の機能のシンクまたはマージ、6. ビジネス量が少ないシステムのリスト。

このうち 1 ～ 4 はシステムの行動指針、原則と言えるもので、5 ～ 6 は次の行動ステップであり、より簡単に言うと私たちがよく行うシステムのシャットダウンと再起動です。事業部門のシステムを停止して移管する場合には、コストの問題も考慮し、コストをしっかりと定量化する必要があります。

まず第一に、シャットダウンと切り替えにかかるコストを評価する必要があり、次に、人的資源やマシンリソースのコストを含む、1 ～ 3 年間のシステムの日常メンテナンスのコストを評価する必要があります。前者と後者の累積値を差し引き、それがゼロより大きければ当面はシステムを動かさないことが推奨され、ゼロ未満であれば停止してひっくり返す計画が検討される。

以上が研究開発の観点から見たシステムアーキテクチャの合理性についての私の考えです。

アーキテクチャの合理性をビジネスの観点から評価すると、次の 3 つの側面が考えられます。まず、現在のビジネスニーズと問題を解決できること。2. ビジネス要件を効率的に完了する: 現在のビジネス上の問題をすべて、洗練された再利用可能な方法で解決できます。3. 将来を見据えた設計: 将来の一定期間は後者の方法でビジネスを満足させることができるため、ビジネスが進化するたびに構造に天地を揺るがすような変化を引き起こすことはありません。

視点が異なるということは、必然的に、同じものについて全員が異なる見解を持っていることを意味します。

著者: 京東リテール高天林

出典: JD Cloud Development Community より転載。出典を明記してください