『中国・台湾のアーキテクチャと実装』読書メモ

『中国・台湾のアーキテクチャと実装』読書メモ

1. マイクロサービス アーキテクチャに基づいてエンタープライズ レベルのアプリケーションを構築することが業界のトレンドになっています。マイクロサービス アーキテクチャはアプリケーションの分離を非常にうまく実現し、アプリケーションをクラウドに適切にプールできるようになり、単一アプリケーションの拡張と不十分な柔軟なスケーラビリティの問題を解決できます。

2. ミドルプラットフォームとしては、エンタープライズレベルのビジネス機能の再利用を実現するために、一般的なビジネス機能をミドルプラットフォームのビジネスモデルに落とし込む必要があります。

3. DDD では、まずビジネス ドメインからビジネス ドメインの境界を手動で分割し、イベント ストーム ワークショップ手法を採用して、ビジネス シナリオ内のエンティティ、値オブジェクト、集約ルート、集約、ドメイン イベントなどのドメイン オブジェクトを分析および抽出します。モデルはマイクロサービス設計の入力として使用され、マイクロサービスの詳細設計が完了します。DDD 手法で設計されたマイクロサービスは、ビジネスとアプリケーションの境界が非常に明確で、「凝集性が高く、統合性が低い」という設計原則に準拠しており、モデルの変更やマイクロサービス アーキテクチャの進化に容易に適応できます。

4. 目次

   • 本書は主に 24 章からなり、全部で 6 部に分かれています。
     第 1 部はミドルプラットフォームを理解する (第 1 章から第 4 章)
     4 つの章で構成されており、主にミドル プラットフォームの背景知識を紹介し、ビジネス センター、データ センターからミドル プラットフォームの本当の意味を知り、理解します。 、テクノロジー センターおよび関連組織のマッチングとその他の側面により、ミドル オフィスの変革において従来の企業が持つべき能力を分析し、DDD がどのようにミドル オフィスとマイクロサービスの設計を導き、明確にするかについての予備的な理解をもたらします。彼らの協力関係。
     第 2 部は DDD の基本原理 (第 5 章から第 11 章) であり、
     DDD をより深く理解できるよう、いくつかのわかりやすい事例を使用して、核となる基礎知識と設計を学び、深く理解するのに役立ちます。 DDD の原理、手法のアイデアなど、「それらの間の連携と依存関係を理解し​​、DDD 概念を理解するという困難な問題を解決」し、中部および台湾での実践に備える。この部分には 7 つの章が含まれており、主にドメイン サブドメイン、コア サブドメイン、一般サブドメイン、サポート サブドメイン、境界コンテキスト 'エンティティ' 値オブジェクト、集約' 集約ルート、ドメイン イベント、および DDD 階層化アーキテクチャを含む DDD の主要なコア知識システムを説明します。その他の知識。
     第 3 部は、ミドル プラットフォームのドメイン モデリングとマイクロサービス設計 (第 12 章から第 19 章) であり、
     主に DDD が戦略設計を通じてミドル プラットフォームのビジネス モデルをどのように構築するか、およびマイクロサービスの分割と移行をどのように誘導するかについて紹介する 8 章で構成されています。戦術的設計によるマイクロサービス設計。このパートでは、複数の実際のケースを使用して、DDD 手法によるミドル プラットフォームとマイクロサービスの全プロセス設計を説明し、ミドル プラットフォーム ドメイン モデリングとマイクロサービス設計における DDD の手順と手法を深く理解し、設計します。考え方と価値観。
     l) イベント・ストーム法を使用してドメイン・モデルを構築する方法を理解します。
     2) DDD 設計アイデアを使用して、エンタープライズレベルの再利用可能なミドルエンドのビジネス モデルを構築する方法を理解します。
     3) DDD を使用してマイクロサービス コード モデルを設計する方法、ドメイン モデルをマイクロサービスにマッピングしてドメイン モデルとマイクロサービス コード モデルの間のマッピング関係を確立する方法、マイクロサービス アーキテクチャの進化を完了する方法などを理解します。最後に、ケースを使用して DDD のすべての知識ポイントを結び付け、DDD の設計手法を使用してドメイン モデリングとマイクロサービス設計のプロセス全体を完了する方法を理解し、コード例を詳細に分析して説明します。 。
     4 番目のパートはフロントエンド設計 (第 20 章と第 21 章) で、
     このパートは 2 つの章で構成されており、主にマイクロ フロントエンドの設計思想を紹介し、フロントエンドのマイクロサービスとユニット化の設計思想を通じて、ビジネスセンターの構築が完了した後にフロントエンドアプリケーションソリューションを解決するには、ポットとフロントエンドおよびバックエンドサービスを統合するのが困難です。本書は、マイクロサービスの設計思想から学び、フロントエンド・アプリケーションを解体する「フロントエンド・アプリケーションの解体を実現する」方法を解説し、実践と組み合わせてフロントエンド・アーキテクチャの変革戦略と技術実装を紹介します。 。さらに、このパートでは、ドメイン モデルに基づいたユニット化された設計手法についても説明します。マイクロサービスとマイクロフロントエンドの組み合わせの統一された設計により、エンタープライズレベルのフロントエンドアプリケーション統合の複雑さが軽減されるだけでなく、企業はより強力な製品の迅速なリリースとビジネス対応能力を得ることができます
     。モデル、ビジネス機能リリースなどが大きな
     価値をもたらします。
     5 番目の部分は、ミドル オフィスの設計ケースです (第 22 章)。
     この部分には、「トップダウン ドメイン モデリング戦略を使用した」保険注文設計ケースを通じて、ミドル オフィス設計の完全なプロセスを説明する章が含まれています。 。ビジネスドメインの分解、中期ドメインのモデリング、マイクロサービスとマイクロフロントエンドの設計、ユニット設計、ビジネスとデータの統合を実現する方法などを取り上げており、DDD、中期の理解が深まる一助となれば幸いです。知識システム、デザイン思考、技術システムを包括的に理解することで、DDD での Taili Microservices の構築実践にさらに効果的に投資できます。
     第 VI 部の要約 (第 23 章と第 24 章)
     この部分は、2 つの章を含む本書全体の要約です。この本は、私の長年の設計経験と考え方を組み合わせたもので、「単一のアプリケーションからマイクロサービス アーキテクチャへの進化戦略を理解するためのガイド」、「DDD 設計でよくある誤解を回避する方法」、「マイクロサービスの設計原則と主要な設計」をまとめています。分散アーキテクチャなど。

5. 背景: 企業、特に巨大企業は、事業がある程度の規模に成長すると、事業の多様性と事業への依存度の高さという問題に直面することがよくあります。そして事業の発展に伴い、企業内の部門はますます増え、分業はますます細かくなり、部門間の依存関係やコミュニケーションコストもますます高くなってきます。

   企業レベルの全体的な計画、市場の変化に迅速に対応する能力、ビジネス モデルの革新を効率的にサポートする
   メカニズムが欠如している場合、企業の運営と革新のコストは大幅に増加します。

   市場対応力を向上させ、ビジネスモデル革新の問題を解決するために、ますます多くの企業がデジタルトランスフォーメーションに挑戦し始めています
   。

6. 従来型企業のデジタル変革の問題点:

   過去 10 年間、モバイル インターネットなどの新しい電子商取引モデルや顧客の消費行動や習慣の変化は、従来の企業に固有のビジネス形態やビジネス モデルを大きく刺激し、影響を与えてきました。従来の企業は、インターネット企業の成功体験から学び、クローズドからオープンに移行し、インターネット ビジネス エコシステムに積極的に統合し始めました。しかし、歴史的［「伝統的企業の技術的負債が多すぎる」ことによるポンプの長期的な技術停滞により、技術力は著しく遅れており、同時に社内のさまざまな部門の間に強固な「部門の壁」が存在しています。企業の「ビジネスとテクノロジーのギャップ」 また、企業のデジタル変革
   には多大な困難をもたらしますが全体として、従来型企業のデジタル変革は、以下の問題の解決に焦点を当てる必要があります。

   • 後進的な技術システムの問題
     ほとんどの伝統的な企業は集中型アーキテクチャを採用しており、技術システムは比較的後進的であり、拡張性は強力ではありません。集中型アーキテクチャはデバイス リソースに大きく依存しており、そのほとんどは安定性やパフォーマンスを考慮してメインフレームまたはミニコンピュータ上で実行されます。同時に、「従来の企業は主に「2拠点3センター」の災害復旧モデルを採用している」高可用性能力が弱く、複数のセンターと複数のアクティビティを実現するのが難しく、リソースの無駄が発生しやすい。
     運用保守能力に関しては、手動操作に依存しすぎて自動運用保守が実現できず、突発的な高頻度アクセスが発生するビジネスシーンにおいては、自動での柔軟なスケーリングが実現できません。ビジネス量がある程度の規模に達すると、一元化されたデータベースの容量と収益性がビジネス展開のボトルネックになりやすくなります。
     全体として、従来の集中型アーキテクチャ技術システムは、新しい形式のビジネス開発要件に適応することが困難でした。
   • モノリシック アーキテクチャの問題
     集中管理されたモノリシック アプリケーションは、複数の機能を 1 つのアプリケーションに組み込む傾向があり、時間の経過とともに、このアプリケーションは大規模で複雑な「モンスター」になります。プロジェクト チームのメンバーが交代するにつれて、時間の経過とともに、論理的なアーキテクチャを完全に理解できる人はほとんどなくなります。従来のコードを改変することで予期せぬバグが発生し、アプリケーションの規模が大きくなり複雑化し、可読性がますます悪くなるのを懸念して、不要なコードを追加しようとする人もいるかもしれません。悪循環に陥った プロジェクトチーム全体にとって、システム開発作業は非常に苦痛なものとなった コードだけでなく、単一アプリケーションにも多くの問題が発生 単一アプリケーションの各モジュールの高度な統合により
     、アプリケーションの場合、ローカルの小さなバグが原因で単一アプリケーション全体が使用できなくなる可能性があります さらに、単一アプリケーションの展開パッケージが大きすぎてクラウド上に実装するのが困難 リソースの柔軟なスケーリングがアプリケーションのスケーラビリティを低下させ、アプリケーションの拡張性を低下させます同時に、「ひとつのアプリケーション全体」の部分的な機能の技術高度化が完了しにくい 企業が新たな技術に挑戦することが難しく、技術力＝停滞の一途 技術が進歩しないと、アップグレードをタイムリーに完了できず、技術的負債がますます増大します。
   • 研究開発、リース、運用、保守の能力が遅れているという問題
     。一般に、単一アプリケーションのプロジェクト チームは大規模であり、通常は従来のウォーターフォール開発モデルを採用します。この開発モデルの欠点は、開発とテストのサイクルに時間がかかり、配信の品質とサイクルを保証することが難しく、継続的かつ迅速な配信が達成できないこと、ビジネス ニーズや市場への対応能力が比較的遅いことです。アジャイル開発を導入するのは難しい。
     さらに、クラウド コンピューティング プラットフォームと自動運用および保守ツールは、単一アプリケーションに対する環境サポートが限られており、アプリケーションの展開および運用および保守のプロセスは比較的複雑です。アプリケーションに問題が発生した場合、基本的に人による検査に基づいており、研究開発チームと運用保守チームが問題を迅速に特定し、連携して解決することが困難です。
   • 重複した IT 機能の構築
     内部ビジネス開発をサポートするために、従来の企業のほとんどは、集中型アーキテクチャを備えた単一のコア システムを構築してきました。過去 10 年間、インターネット電子商取引ビジネスの急速な発展に伴い、多くの伝統的な企業は従来のビジネスを維持し、モバイル インターネット エコシステム向けの新しいビジネスを開発する必要がありました。従来の集中型テクノロジー システムと研究開発モデルでは、インターネットの大規模かつ同時実行性の高いビジネス要件をサポートすることが困難であるという事実により、従来のコア インターネット アプリケーションとモバイル インターネット アプリケーション間の相互影響を回避するために、多くの企業は分散型テクノロジー システムを採用しています。ただし、両者は同種の製品を販売しているため、基本機能モジュール k に交差部分があり、ホイールの作成が繰り返されるという問題があります。
     従来のコア アプリケーションとモバイル インターネット アプリケーションの繰り返しの構築に加えて、ビジネスの同質性の問題もさまざまなビジネス シナリオやチャネルで発生しています。均質なビジネスを行うこれらのさまざまなチャネルは、繰り返し建設される場合に最も大きな打撃を受ける領域でもあります。
     また、グループ内においては、IT構築の全体計画が欠如しているため、子会社間で公共事業機能（顧客等）の構築が繰り返し行われる問題がより顕著になる可能性があります。
     非常に多くの伝統的な企業が、「デュアルコア」や「安定性と機密性の高いデュアルステート」について議論しています。では、なぜそのような問題が主に伝統的な企業で発生し、新しいインターネット企業では発生しないのでしょうか? 根本的な原因は次のとおりだと思います
     。従来の技術システム、研究開発モデル、およびビジネスモデルが、従来のインターネットビジネスとモバイルインターネットビジネスの発展の間の矛盾を同時に処理するための。まとめる
     と、反復的なIT構築の問題を解決するには、エンタープライズレベルのビジネス能力の再利用を実現するための技術力の向上とビジネスモデルの人員の再構築が必要です。これはデジタル分野でも解決すべき課題です。伝統的な企業の変革。

7. ドメイン層のコード構造

   • Leave マイクロサービス ドメイン層には、Leave と人事の 2 つの集合体があります。Leave コードと Ren Yuan コードは、それぞれの集合体が配置されているディレクトリ構造に別々に配置されます。ビジネスの発展に伴い、人事関連の機能を休暇マイクロサービスから分離する必要がある場合は、人事集約コード ディレクトリを全体として削除し、独立してデプロイし、新しい人事マイクロサービスとして迅速にリリースするだけで済みます。

8. マイクロサービスを設計および開発するときは、マイクロサービス アーキテクチャの進化を常に考慮する必要があり、将来的にはアグリゲーションの分離とアグリゲーションの再編成を考慮する必要があります。デカップリング後は、マイクロサービスの境界がより明確になり、ビジネスの急速な変化に適応しやすくなり、マイクロサービスアーキテクチャの進化が実現しやすくなり、当然フロントエンドのビジネスニーズの変化にも対応できるようになります。もっと早く。

9. 例: 中国・台湾戦略に基づく保険注文ベースの設計。DDDベースの中台建設の核となる知識体系と設計思想を深く理解する