前書き
建築スタイルの選択は、情報システムを構築する上での基本的な技術的解決策の1つです。このシリーズの記事では、アプリケーションを構築するための最も人気のあるアーキテクチャスタイルを分析し、いつ最も好ましいアーキテクチャスタイルであるかという質問に答えることを提案します。その過程で、モノリスからマイクロサービスまでの建築スタイルの開発を説明する論理的な連鎖をたどろうとします。最後の時間は、我々はモノリスに対処し、モノリスは、多くの問題があるという結論に達した：サイズ、接続性、展開、拡張性、信頼性、保守主義を。
今回は、モジュール/ライブラリ（コンポーネント指向のアーキテクチャ）またはサービス（サービス指向のアーキテクチャ）のセットの形でシステムを編成する可能性についてお話しすることを提案します。
コンポーネント指向のアーキテクチャ
コンポーネントベースのアーキテクチャは、現在および将来のプロジェクトの両方で使用できるコンポーネントのセットとしてシステムを実装することを意味します。システムをコンポーネントに分割する場合、次の要素が考慮されます。再利用への適合性、交換可能性、コンテキストからの独立性、拡張性、カプセル化、および独立性。
コンポーネントを適切に使用することで、「大きな汚れの球」（大きなサイズ+高い接続性）の問題が解決され、コンポーネント自体がアセンブリユニット（モジュール、ライブラリ）と展開ユニット（サービス）の両方になります。展開ユニットは、実行中のプロセスに常にマップされるとは限りません。たとえば、Webアプリケーションとデータベースは一緒に展開されます。
ほとんどの場合、モノリスはモジュールのセットとして設計されます。このアプローチは、開発の独立性を確保することにつながりますが、同時に、独立したスケーリングと展開、障害耐性、および一般的な技術スタックからの独立性の問題が残ります。これが、モジュールが部分的に独立したコンポーネントである理由です。
このようなモノリスの最大の問題は、モジュールへの分割が純粋に論理的であり、開発者が簡単に破ることができることです。コアモジュールが表示され、徐々にゴミの山に変わったり、モジュール間の依存関係のグラフが大きくなったりする場合があります。このような問題を回避するには、開発は非常に成熟したチームによって、またはコードレビューにフルタイムで従事し、論理構造に違反する開発者の手を打ち負かす「アーキテクト」の指導の下で実行する必要があります。
「理想的な」モノリスは、論理的に分離されたモジュールのセットであり、各モジュールは独自のデータベースを調べます。
サービス指向アーキテクチャー
それでも、システムを一連のサービスの形で編成することになっている場合は、サービス指向のアーキテクチャについて話します。その原則は、ユーザー指向のアプリケーションの相互運用性、ビジネスサービスの再利用性、一連のテクノロジーからの独立性、および自律性（独立した進化、スケーラビリティ、および展開）です。
サービス指向アーキテクチャ（SOA）は、モノリスで概説されているすべての問題を解決します。変更は1つのサービスにのみ影響し、明確に定義されたAPIは適切なコンポーネントのカプセル化をサポートします。
しかし、すべてがそれほどスムーズであるとは限りません。SOAは新しい問題を引き起こします。リモート通話はローカル通話よりも費用がかかり、コンポーネント間での責任の再配分は大幅に費用がかかります。
ちなみに、独立して展開する機能は、サービスの非常に重要な機能です。サービスを一緒に展開する場合、または特定の順序で展開する場合は、システムをサービス指向と見なすことはできません。この場合、彼らは分散モノリスについて話します（SOAの観点からだけでなく、マイクロサービスアーキテクチャの観点からもアンチパターンと見なされます）。
サービス指向のアーキテクチャは、アーキテクチャコミュニティとベンダーによって十分にサポートされています。したがって、多くのコースと認定、よく発達したパターンがあります。後者には、たとえば、未知ではないエンタープライズサービスバス（ESB =エンタープライズサービスバス）が含まれます。同時に、ESBはベンダーからの手荷物であり、SOAで使用する必要はありません。
サービス指向のアーキテクチャの人気は2008年頃にピークに達し、その後減少し始めました。マイクロサービスの出現後、それははるかに鋭くなりました（〜2015）。
結論
サービスとモジュールの形で情報システムを編成する可能性について説明した後、最終的にマイクロサービスアーキテクチャの原則に移り、次のパートでマイクロサービスアーキテクチャとサービス指向アーキテクチャの違いに特に注意を払うことを提案します。
