マイクロサービスとビジネスミドルプラットフォームの設計共有
1. ビジネスセンター
共通の特徴
ビジネスセンターは集中工法です
ビジネスセンターはドメイン指向のアーキテクチャシステムです
ビジネスプラットフォームはオンデマンドで利用される製品形態であり、必要に応じて従量課金のビジネスモデルにすることも可能
ユニークな特徴
ビジネス プラットフォームは技術的にはマイクロサービス アーキテクチャです
ビジネスセンターはビジネスにおけるイノベーション指向のアーキテクチャです
ビジネスセンターには、ビジネス推進者を受け入れ、ビジネス開発をサポートするポジティブフィードバックメカニズムが必要です。
コア競争力
迅速なビジネス対応能力
大規模な革新的な機能
試行錯誤のコストを削減
実行する方法
ドメイン駆動設計 (DDD)
問題空間とビジネス ロジックを分析してアプリケーションをドメインとして定義する
ドメインは複数のサブドメインで構成され、それぞれがビジネスの異なる部分に対応します。
サブドメインに対応したサービス設計
サブドメインの分類
コア クラス - ビジネスの主要な差別化要因であり、アプリケーションの最も価値のある部分です。（ビジネスミドルエンドサービス候補）
サポートクラス - ビジネスに関連しますが、差別化にはなりません。（ビジネスフロントサービス候補者）
ジェネリック クラス - ビジネスに依存せず、理想的には既製のソフトウェアを使用して実装できます。
ビジネスセンターではないもの
ビジネス センターによって提供される機能は共有できません。ビジネス センターでは共有できません。
新たなビジネス要件や要件の変更がある場合、厳密なビジネスミドルプラットフォームではなく、ビジネスミドルプラットフォームを変更する必要があります
フォアグラウンドがミドル プラットフォームを呼び出し、ミドル プラットフォームがフォアグラウンドの呼び出しリンクを呼び出す場合、それは合理的なビジネス ミドル プラットフォームではありません。
2. マイクロサービス
マイクロサービス分割方法
(1) ビジネスドメインをビジネス境界に応じて複数のビジネスサブドメインに分割（複数のマイクロサービスに対応）
(2) ビジネスサブドメインを複数のドメインオブジェクト（特定のマイクロサービス下の複数のサービスに相当）に分解する
(3) ドメイン オブジェクトの複数のドメイン アクティビティを識別し、ドメイン オブジェクトに関係するビジネス アクティビティをカバーします (ドメイン アクティビティはサービスのメソッドに対応します)
(4) ドメインアクティビティに関与する集合体、エンティティ、および値オブジェクト（マイクロサービスのエンティティオブジェクトとデータオブジェクトに相当）を特定する
(5) 異なるサブドメインを比較します。類似したドメイン オブジェクト、ドメイン アクティビティ、集計、エンティティ、および値オブジェクトを分析し、特定の類似性しきい値に従ってマージおよび重複を排除します。
(6) 同じサブドメインを分析します。異なるサービス間に相互作用がない場合は、さらに異なるマイクロサービスに分割できます。
(7) ステップ 1 ～ 6 を繰り返し実行し、分割の合理性を継続的に向上させます
分析例
すべてのビジネス ユース ケースは、アプリケーションと技術アーキテクチャの観点から、人間とコンピューターの対話、ロジック処理、データ ストレージの 3 つのレベルに分類できます。
フロントデスクとミドルデスクの部門は、「元吉処理とデータストレージ」の下位部門に重点を置いています
したがって：
(1) マイクロサービスの垂直分割の結果を踏まえ、さらに水平分割を行う
(2) 人間とコンピュータの対話はビジネス アプリケーションに属する
(3) ビジネス アプリケーションに属する、変更可能なトランザクション ロジックの処理とデータ ストレージ
(4) ビジネスサポートに属する安定した基本的なロジック処理とデータストレージ
マイクロサービスではないもの
マイクロサービスではなく、異なるチームによる並行開発のために分割されるだけです
データベースを分割しないとマイクロサービスではない
経験のフィードバック
各マイクロサービスはデータベースに対応しますが、関連するクエリ要件がある場合は、可能な限り同じインスタンスに保存する必要があります。
ビジネスのミドルエンド サービスはできるだけ多くありませんが、重要なのは、ビジネスの性質を洞察し、常にプロセス指向の設計ではなくリソース指向の設計を維持することです。
ビジネスの中間のサービスによって提供される機能の粒度は、通常、フォアグラウンド サービスの粒度よりも細かくなります。
ビジネスミドルプラットフォームは、複雑なビジネスロジックと頻繁なビジネスの変更と革新を伴うビジネスシナリオに適しています。
ビジネスミドルプラットフォームは事前に開発・デバッグする必要があり、ビジネスフロントと並行することはできません。ビジネスフロントデスクの開発を開始するときは、ビジネスミドルプラットフォームAPIが安定している必要があります
ビジネス フロント デスクとビジネス ミドル デスクは API ゲートウェイを介して対話し、ルーティング、電流制限、認証、監視などの多くの非ビジネス機能が API ゲートウェイによって提供されます。
業務管理・制御をビジネスミドルプラットフォームとして構築するのではなく、管理・制御とは処理ロジックや処理を意味し、ビジネスフロントがビジネスミドルプラットフォームの機能を利用し、組み合わせ・整理することで実現すべきである。
3. まとめ
フロントエンドとバックエンドを必ず分離してください
バックエンドはマイクロサービスを分割してマイクロサービスのセットを形成します
分割の原則により、中間者サービスとフロントエンドサービスを識別する
フロントエンドサービスとフロントエンドサービスを合わせて「ビジネスフロントデスク」を形成します。
ミドルエンドのサービスを合わせて「ビジネスミドルエンド」を形成
引き続きステップ 3 ～ 5 を繰り返します