集約、イベントソーシング、CQRSを使用したトランザクションマイクロサービスの開発（パート1）

マイクロサービスアーキテクチャを使用してトランザクションビジネスアプリケーションを開発する方法に関する有用な記事の最初の部分の翻訳に注目してください。



マイクロサービスアーキテクチャはますます一般的になりつつあります。 これは、アプリケーションが機能的に個別のサービスに分割されるモジュラーアプローチです。 その結果、大規模で複雑なアプリケーションの開発者は、高品質のソフトウェアを迅速に作成できます。 このアプローチでは、最も適切で最新のテクノロジースタックを使用して個々のサービスを実装することが可能になるため、新しいテクノロジーを習得しやすくなります。 マイクロサービスアーキテクチャは、個々のサービスを最適な機器に展開できるため、アプリケーションのスケーラビリティも向上します。



ただし、マイクロサービスはそれほど単純で普遍的なソリューションではありません。 特に、ドメインモデル、トランザクション、およびクエリは、機能的な分離に対して驚くほど耐性があります。 その結果、マイクロサービスアーキテクチャを使用したトランザクションビジネスアプリケーションの開発は非常に困難です。 この記事では、ドメインドリブンデザイン、イベントソーシング、CQRSを使用してこれらの問題を解決するマイクロサービスを開発する方法を検討します。



キーポイント：

• マイクロサービスアーキテクチャは、アプリケーションを機能的に個別のサービスに分割します。各サービスは、特定のビジネスオブジェクトまたはビジネスプロセスに対応します。
• マイクロサービス指向アプリケーションの開発における重要な問題の1つは、トランザクション、ドメインモデル、およびクエリが、分離されたサービスに分離することを「抵抗」することです。
• ドメインモデルは、ドメインドリブンデザインパターンの一部として、集計（集計）に分解できます。
• 各サービスは、1つ以上のDDD集合体で構成されるドメインモデルです。
• サービス内で、各トランザクションは単一のユニットを作成または更新します。
• イベントは、集合体（およびサービス）間の一貫性を維持するために使用されます。

最初に、開発者がマイクロサービスを作成するときに直面する問題を見てみましょう。

マイクロサービス開発の問題

モジュール化は、大規模で複雑なアプリケーションを開発する際に重要です。

最新のアプリケーションのほとんどは、1人の開発者が作成するには大きすぎます。 さらに、それらは複雑すぎて1人では完全に理解できません。 アプリケーションは、開発者チーム全体で開発されたモジュールに分割する必要があります。 モノリシックアプリケーションでは、モジュール性は、Javaパッケージなどの使用されるプログラミング言語の構造によって決まります。 原則として、このアプローチは実際にはうまく機能しません。 長寿命のモノリシックアプリケーションは、通常、アンチパターンビッグボールオブ泥と呼ばれるものに退化します。



マイクロサービスアーキテクチャは、サービスをモジュール化の単位として使用します。 各サービスは、特定の結果を得るために何かを行う個別のビジネスプロセスまたはビジネスオブジェクトです。 たとえば、このアーキテクチャを使用するオンラインストアは、注文サービス、顧客サービス、カタログサービスなどのマイクロサービスで構成できます。







各サービスには明確な境界があり、長期にわたってアプリケーションのモジュール性を維持することがはるかに容易になります。 マイクロサービスアーキテクチャには、サービスを独立して展開および拡張する機能など、他の利点もあります。



残念ながら、アプリケーションをサービスに分割することは見た目ほど簡単ではありません。 前述のように、アプリケーションのいくつかの異なる側面（ドメインモデル、トランザクション、クエリ）を分離するのは困難です。 これらの困難の原因を見てみましょう。

問題＃1：ドメインモデルの分離

ドメインモデルパターンは、複雑なビジネスロジックを実装するための良い方法です。 オンラインストアのドメインモデルには、 Order 、 Order Position 、 Customer 、 Productなどのクラスが含まれます。 マイクロサービスアーキテクチャでは、 OrderクラスとOrder LineクラスはOrderサービスの一部であり、 ClientクラスはClientサービスの一部であり、 ProductクラスはCatalogサービスに属します。







ドメインモデルをサービスに分割する際の問題は、クラスが相互に参照することが多いことです。 たとえば、 注文は注文を行った顧客を指し、 注文 アイテムは商品を指します。 サービスの境界に違反するリンクをどうするか？ 後で、DDD（ Domain Driven Design ）の集約（Aggregate）の概念がこの問題をどのように解決するかを見ていきます。

マイクロサービスとデータベース

マイクロサービスアーキテクチャの特徴は、サービスに属するデータにこのサービスのAPIを介してのみアクセスできることです。 たとえば、オンラインストアでは、Order ServiceにORDERSテーブルを含むデータベースがあり、Customer ServiceにはCUSTOMERSテーブルを含む独自のデータベースがあります。 このカプセル化により、サービスは疎結合になり、開発者は他のサービスで作業する開発者と調整する必要なく、サービスのスキームを変更できます。 実行時に、サービスは相互に分離されます。 たとえば、サービスは、別のサービスに属するデータベースロックが終了するのを待ちません。 一方、データベースを機能的に分離すると、データの整合性を維持すること、および多くの種類のクエリを実装することが難しくなります。

問題2：トランザクション

従来のモノリシックアプリケーションは、 トランザクションに依存してビジネスルールを適用できます。 たとえば、オンラインストアの顧客がクレジット制限を持っているとします。クレジット制限は、新しい注文を作成する前に確認する必要があります。 アプリケーションは、注文を同時に数回試行しても、クライアントの信用限度を超えないようにする必要があります。 注文と顧客が同じデータベースにある場合、問題に対する簡単な解決策は、トランザクションを使用することです（適切な分離レベルで）。

BEGIN TRANSACTION … SELECT ORDER_TOTAL FROM ORDERS WHERE CUSTOMER_ID = ? … SELECT CREDIT_LIMIT FROM CUSTOMERS WHERE CUSTOMER_ID = ? … INSERT INTO ORDERS … … COMMIT TRANSACTION
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

残念ながら、このような単純なアプローチを使用して、マイクロサービス指向のアプローチでデータの一貫性を維持することはできません。 ORDERSテーブルとCUSTOMERSテーブルは異なるサービスに属し、APIを介してのみアクセスできます。 さまざまなデータベースに存在することもできます。



この場合、 分散トランザクションが従来のソリューションになりますが、最新のアプリケーションではこれは適切なテクノロジーではありません。 CAP定理では、開発者は可用性と一貫性のどちらかを選択する必要があり、通常はアクセシビリティが推奨されます。 さらに、ほとんどのNoSQLデータベースなどの多くの最新テクノロジーは、分散トランザクションはもちろんのこと、通常のトランザクションもサポートしていません。 整合性を維持することも重要なので、別のソリューションが必要です。 以下に、ソリューションがイベントソーシングに基づいたイベント駆動型、メッセージ駆動型アーキテクチャを使用することであることを示します。

問題3：データベースクエリ

データの整合性を維持することに加えて、データベースクエリは問題です。 従来のモノリシックアプリケーションでは、結合を使用したクエリは非常に一般的です。 たとえば、最近登録した顧客とその大口注文をクエリで簡単に見つけることができます。

 SELECT * FROM CUSTOMER c, ORDER o WHERE c.id = o.ID AND o.ORDER_TOTAL > 100000 AND o.STATE = 'SHIPPED' AND c.CREATION_DATE > ?
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この種のリクエストは、マイクロサービス指向のオンラインストアでは使用できません。 前述のように、ORDERSおよびCUSTOMERSテーブルはさまざまなサービスに属し、APIを介してのみアクセスできます。 一部のサービスでは、SQLデータベースを使用しない場合があります。 ただし、イベントソーシングと呼ばれるアプローチを使用すると、情報の検索がさらに難しくなります。



解決策は、Command Query Responsibility Segregation（CQRS）と呼ばれるアプローチを使用して実体化された表現を保存することであることが後でわかります。 しかし、最初に、マイクロサービスを設計するときにドメイン駆動設計（DDD）を見てみましょう。

DDDはマイクロサービスのビルディングブロックとして集約します

ご覧のとおり、マイクロサービスを使用したアプリケーションの開発を成功させるには、いくつかの問題を解決する必要があります。 これらの問題のいくつかに対する解決策は、エリック・エヴァンスの必読の本「 ドメイン駆動設計 」にあります。 マイクロサービスを開発する際に非常に役立つ、複雑なソフトウェアを設計するアプローチについて説明します。 特に、ドメイン駆動設計では、サービス全体に分散できるモジュラードメインモデルを作成できます。

集計とは何ですか？

ドメイン駆動設計では、Evansはドメインモデルのいくつかの構成要素を定義します。 それらの多くは、エンティティ、値オブジェクト、サービス、リポジトリなどを含む開発者の日常言語の一部になっています。 ただし、1つのビルディングブロック-集合体-は、DDDの純粋主義者を除き、開発者によってほとんど無視されました。 しかし、集約はマイクロサービスを開発するための鍵であることがわかりました。



集合体は、全体として考えることができるドメインオブジェクトのクラスターです。 ルートエンティティオブジェクト（Entity）と、場合によっては、1つ以上の他の関連するエンティティオブジェクトと値オブジェクト（Valueオブジェクト）で構成されます。 たとえば、オンラインストアのドメインモデルには、 OrderやCustomerなどの集計が含まれます。 Order集計は、ルートエンティティOrder 、1つ以上の値オブジェクトOrder位置、およびCost 、 Delivery address、 Payment detailsなどの他の値オブジェクトで構成されます。 Customer集計は、 Customerエンティティと、 配達 情報や支払い情報などの複数の値オブジェクトで構成されます。







集計を使用すると、ドメインモデルが個々に理解しやすいチャンクに分割されます。 また、ロードやアンインストールなどの一連の操作も定義します。 通常、集計はデータベース全体からロードされます。 集約を削除すると、すべてのオブジェクトも削除されます。 ただし、集約は特定のルールに従う必要があるため、集約の利点はドメインモデルのモジュール性をはるかに超えています。

集合間通信では主キーを使用する必要があります

最初の規則は、オブジェクトへの直接参照ではなく、一意の識別子（たとえば、主キー）を介して集計が常に相互に参照することです。 たとえば、 注文は顧客オブジェクトへの参照ではなく、 顧客IDを使用して顧客を参照します。 同様に、 注文 項目はProductIDを使用して製品を参照します。







このアプローチは、ドメインモデルの外部キーが悪い慣行であると見なされる従来のアプローチとは大きく異なります。 オブジェクトへの参照ではなく識別子を使用すると、集計が疎結合されます。 さまざまなユニットをさまざまなサービスに簡単に配置できます。 実際、サービスのビジネスロジックは、集約のセットであるドメインモデルで構成されています。 たとえば、OrderServiceには集約Orderが含まれ、CustomerServiceには集約Customerが含まれます。

1つのトランザクションが1つの集約を作成または更新します

2番目のルールは、トランザクションが1つの集約のみを作成または更新できることです。 私が何年も前にこの規則について初めて読んだとき、それは意味がありませんでした！ 当時、私はRDBMSに基づく従来のモノリシックアプリケーションを開発していたため、トランザクションは任意のデータを更新できました。 現在、この制限はマイクロサービスアーキテクチャに最適です。 これにより、トランザクションがサービス内に含まれることが保証されます。 この制限は、ほとんどのNoSQLデータベースのトランザクション制限にも準拠しています。



ドメインモデルを開発する場合、重要なのは、特定の各集約を実行する必要がある大きさを決定することです。 理想的には、単位は小さくする必要があります。 これにより、責任を共有することでモジュール性が向上します。 通常、ユニットは完全にロードされるため、これはより効率的です。 さらに、各アグリゲートは順次更新されるため、小さなアグリゲートを使用すると、アプリケーションが処理できる同時リクエストの数が増え、スケーラビリティが向上します。 また、2人のユーザーが同じ実装を同時に更新しようとする可能性を減らします。



一方、集約はトランザクションのドメインであるため、特定の更新をアトミックにするために、より大きな集約を定義する必要がある場合があります。



たとえば、上記では、オンラインストアのサブジェクトエリアのモデルでは、 注文とクライアントは別々のユニットであると言われています。 別の方法は、 注文を顧客ユニットの一部にすることです。 大規模な顧客集計の利点は、アプリケーションが与信限度の検証をアトミックに提供できることです。 このアプローチの欠点は、同じサービス内で注文とクライアントの機能を結合することです。 同じ顧客の異なる注文を更新するトランザクションを並行して実行できないため、スケーラビリティが低下します。 さらに、同じ顧客のさまざまな注文を編集しようとすると、2人のユーザーが競合する可能性があります。 ユニットの読み込み、注文数の増加に伴い、 クライアントはますます高価になります。 これらの問題のため、ユニットをできるだけ小さくすることをお勧めします。



トランザクションによって1つの集約のみを作成または更新する必要がある場合でも、アプリケーションは集約間の一貫性を維持する必要があります。 たとえば、 注文サービスは、新しい注文単位が顧客の総与信限度を超えていないことを確認する必要があります。 一貫性を維持する方法はいくつかあります。 1つのオプションは、アプリケーションをだまして、1つのトランザクションで複数の集約を作成/更新することです。 これは、すべてのユニットが同じサービスに属し、同じRDBMSに格納されている場合にのみ可能です。 別のより適切なオプションは、イベント駆動型のアプローチを使用して集計間の一貫性を維持することです。

イベントを使用してデータの一貫性を維持する

最新のアプリケーションにはさまざまなトランザクション制限があり、サービスのデータの一貫性を維持することが困難です。 各サービスには独自のデータがありますが、分散トランザクションの使用は実行可能なオプションではありません。 さらに、多くのアプリケーションは、分散トランザクションはもちろんのこと、通常のローカルトランザクションもサポートしていないNoSQLデータベースを使用しています。 したがって、最新のアプリケーションでは、Eventually Consistentと呼ばれるイベント駆動型のトランザクションモデルを使用する必要があります。

イベントとは何ですか？

Merriam-Webster辞書 （およびCaptain Evidence）が述べているように、「イベント」は何が起こるか（起こる）です。







この記事では、集計に何が起こったかをドメインイベントと定義します。 通常、イベントは状態の変化です。 たとえば、 注文単位を考えてみましょう。 彼の状態を変えるイベントは作成された注文を含んでいます、 注文はキャンセルされて 、 注文は送られます。 イベントは、ビジネスルール、たとえばクライアントの信用限度に違反する試みを構成する場合があります。

イベント駆動型アーキテクチャの使用

サービスは、次のようにイベントを使用して集約間の一貫性を確保します。集約は、目立った何かが発生するたびにイベントを発行します。 たとえば、彼の状態が変化している、またはビジネスルールに違反する試みがあります。 他の集約は、イベントをサブスクライブし、独自の状態を更新することでそれに応答します。



オンラインストアは、次の一連の手順を使用して注文を作成するときに、クライアントの与信限度を確認します。

1. NEWステータスで作成されたOrder集約は、OrderCreatedイベントを発行します。
2. 顧客集計は、OrderCreatedイベントに関する通知を受け取り、 注文のクレジットを予約し、CreditReservedイベントを発行します。
3. OrderユニットはCreditReservedイベントに関する通知を受け取り、そのステータスをAPPROVEDに変更します。

資金不足のために信用調査が失敗した場合、 顧客集計はCreditLimitExceededイベントを投稿します。 このイベントは状態の変化を反映していませんが、ビジネスルールに違反する試みは失敗しています。 注文ユニットはこのイベントに関する通知を受信し、ステータスをキャンセルに変更します。

イベント駆動型集合体のネットワークとしてのマイクロサービスアーキテクチャ

このアーキテクチャでは、各サービスのビジネスロジックは1つ以上の集計で構成されます。 サービスによって実行される各トランザクションは、1つの集約を更新または作成します。 サービスは、イベントを通じて集計間のデータの一貫性を維持します。







このアプローチの特徴は、ユニットが疎結合のビルディングブロックであることです。 これらは、モノリシックアプリケーションとしても、一連の別個のサービスとしても展開できます。 プロジェクトの開始時には、モノリシックアーキテクチャを使用できます。 その後、アプリケーションおよび開発チームの規模が拡大しているため、マイクロサービスアーキテクチャに簡単に切り替えることができます。

まとめ

マイクロサービスアーキテクチャは、機能的にアプリケーションをサービスに分割します。各サービスは、特定のビジネスオブジェクトまたはビジネスプロセスに対応します。 マイクロサービスビジネスアプリケーションの開発における主な問題の1つは、トランザクション、ドメインモデル、およびクエリがサービスの共有に反対することです。 Domain Driven Designの「集約」コンセプトを使用して、ドメインモデルを分離できます。 各サービスのビジネスロジックは、1つ以上のDDD集計で構成されるドメインモデルです。



各サービス内で、トランザクションは単一の集約を作成または更新します。 分散トランザクションは最新のアプリケーションにとって実行可能なテクノロジーではないため、イベントは集約（およびサービス）間の一貫性を維持するために使用されます。



記事の第2部では、Event Sourcingを使用して堅牢なイベント駆動型アーキテクチャを実装する方法と、CQRSを使用してマイクロサービスアーキテクチャにクエリを実装する方法について説明します。