3.2 アーキテクチャスタイルとパターン

概要と動機

アーキテクチャスタイルとは、システムを組織するための、広く再利用できる形です。どう分解され、部品がどう通信し、境界がどこに落ちるか。それを選ぶことは、大きな組織が下す、最も重大で最も誤解されている決定の一つです。選択がチーム、ドメイン、運用の現実という本物の制約ではなく、流行(「みんなマイクロサービスをやっている」)に従うことがあまりに多くあります。そして二つの混乱のどちらかに行き着きます。組織が運用できない分散システムか、誰も安全に変更できない絡まったモノリスか。どちらもスタイルのせいではありません。どちらもスタイルを状況に合わせ損ねたことから来ます。

大きな開発者チームにとって、スタイルが何より重要なのはコンウェイの法則のためです。システムの構造は、それを作る組織のコミュニケーション構造を映す傾向があります。だからアーキテクチャスタイルは、組織設計の決定でもあります。システムをサービスに分割することは、実のところ、チーム、オーナーシップ、オンコールの責任を分割する決定です。何百人ものエンジニアを持つ企業は、独立したデプロイを伴う細粒度のサービスを持つ余裕があり(しばしば必要とし)、その独立性こそが、多くのチームが互いをブロックせずに出荷する方法だからです。同じパターンを一つの小さなチームに強いれば、組織的な利益なしに、運用の税のすべてを引き継ぎます。

政府や企業の設定は、さらに制約を積み上げます。長いシステムの寿命、厳格な変更管理、調達のサイクル、根づいた記録のシステムとの統合、監査可能性。これらは、境界を明示的に保ち、依存関係を検査しやすいスタイルを有利にします。本章は主要なスタイルを概観します。モノリスからマイクロサービス、CQRSとイベントソーシングを伴うイベント駆動アーキテクチャ、サービスメッシュとゲートウェイのパターン、サーバーレス、そしてヘキサゴナルとクリーンアーキテクチャの内部の規律。それ以上に重要なのは、それぞれがいつ合うかを見分ける助けになることです。

関連項目: 2.2章(ソフトウェア設計原則、ドメイン駆動設計を含む)、3.1章(アーキテクチャの基礎)、3.3章(分散システム)。

主要原則

スタイルは流行ではなく、力に従う。 技術が人気だからではなく、チームの規模、ドメインの複雑さ、負荷、運用の成熟度に基づいて選びます。
本当の敵は、デプロイ可能なものの数ではなく、結合である。 よくモジュール化されたモノリスは、分散したビッグボールオブマッドに勝ります。
分散は、独立性のために払うコストである。 独立したデプロイ、スケーリング、障害の隔離の価値が、ネットワーク呼び出し、部分的な失敗、サービス間のデータの一貫性のコストを上回るときにだけ分割します。
境界はビジネスのドメインに従うべきである。 サービスとモジュールを、技術的な層ではなく、境界付けられたコンテキスト(それぞれが独自の明示的な境界を持つ、自己完結したドメインモデル)に合わせます。
外側がどうであれ、内側をよく設計する。 ヘキサゴナル/クリーンの層構造は、どのスタイルでも、ビジネスロジックをフレームワークとインフラから独立に保ちます。
コンウェイの法則は避けられないので、使う。 チームの境界とアーキテクチャを一緒に設計します。
必要だと思うより単純に始める。 良いモジュラーモノリスからサービスを取り出せます。早すぎるマイクロサービスの混乱を分散から戻すのは、はるかに困難です。

推奨事項

モジュラーモノリスを既定とし、証拠をもって分割する

ほとんどのシステムを、強い内部のモジュール境界を伴う単一のデプロイ可能な単位として始めます。明確なインターフェース、別のモジュールのデータに手を伸ばさないこと、徹底された依存ルール。単純なトランザクション、容易なリファクタリング、デプロイして観察する対象が一つ、という利益が得られます。具体的な理由があるときにだけ、モジュールを独自のサービスに分割します。単独でスケールしなければならない部分、独自の周期でデプロイする必要のあるチーム、隔離しなければならない障害ドメイン、残りと異なる技術要件。分割するときは、各サービスが自分のデータを所有し、安定した契約を公開するよう、境界付けられたコンテキストの線に沿って分割します。

マイクロサービスがその価値を稼ぐときを知る

マイクロサービスは、独立したデプロイ可能性、独立したスケーリング、障害の隔離、技術を混ぜる自由を与えます。その代わり、成熟したCI/CD(継続的インテグレーションと継続的デリバリー)、自動化されたインフラ、分散トレーシング、サービスディスカバリ、オンコールの文化を要求します。正直に自問してください。組織は、独立してデプロイされる数十のサービスを本番で確実に運用できるか。プラットフォームと運用の成熟度がなければ、マイクロサービスは利益を届けずに失敗モードを増やすだけです。多くの組織は、小さなサービスの群れではなく、主要なドメインに合わせた少数の粗粒度のサービスで最良になります。

疎結合と非同期が見返りをもたらす所で、イベント駆動アーキテクチャを使う

イベント駆動アーキテクチャは、生産者が、誰が消費するかを知らずに事実を発することを可能にします。それが、疎結合、負荷の急増へのバッファ、新しい消費者を加える容易な方法を買います。ワークフローが自然に非同期で反応的な所で使います。CQRS(コマンドクエリ責任分離)は、書き込みモデルを一つ以上の読み取りモデルから分離し、読み取りと書き込みの負荷や形が大きく異なるときに役立ちます。イベントソーシングは、状態を現在の状態ではなく追記専用のイベントのログとして保存し、完全な監査証跡とタイムトラベルを与えます。「どうやってこの値に至ったか」が法的な問いである金融と政府にとって強力ですが、イベントのバージョニング、プロジェクションの再構築、結果整合性についての推論に、本物の複雑さを加えます。既定ではなく、意図してこれらに手を伸ばします。

多くのサービスを管理するために、ゲートウェイ、BFF、メッシュのパターンを適用する

APIゲートウェイは、外部のクライアントに単一の入口を与え、認証、レート制限、ルーティング、TLS(トランスポート層セキュリティ)終端を扱います。Backend-for-Frontend(BFF)は、各クライアントの種類(ウェブ、モバイル、パートナーAPI)に独自に調整された集約層を与え、肥大した画一的なAPIを避けられます。サービスメッシュは、横断的関心事(相互TLS、リトライ、タイムアウト、トラフィックのシフト、テレメトリ)をサイドカーのインフラ層に移し、アプリケーションチームがそれらを再実装しなくて済むようにします。サービスの数が、これらの関心事をサービスごとに扱うことを手に負えなくしたときにだけメッシュを加えます。少数のサービスでは、メッシュは見合う以上の運用の重さです。

サーバーレスを正直に量る

Function-as-a-serviceとマネージドなサーバーレスのプラットフォームは、サーバー管理をあなたの皿から取り除き、ゼロまでスケールし、使用量に応じて課金するので、急増する、イベント駆動の、あるいはベースラインの低いワークロードや、小さなチームに最適です。トレードオフは本物です。コールドスタートのレイテンシ、実行時間とリソースの制限、より難しいローカルテスト、ベンダーロックインの可能性、持続的な高い量ではプロビジョニングされたインフラを上回りうるコスト。経済性と運用の単純さが明らかに勝つ所でサーバーレスを使います。熱意から、安定した高スループットの中核システムを無理に押し込んではいけません。

あらゆるサービスの内側でビジネスロジックをきれいに保つ

外側のスタイルが何であれ、ヘキサゴナル(ポートとアダプター)かクリーンアーキテクチャで、内側をきれいに保ちます。ビジネスルールを中心に置き、抽象にのみ依存させ、フレームワーク、データベース、メッセージングを、置き換え可能なアダプターとして縁に置く。これにより、価値あるドメインロジックがインフラなしにテスト可能で、技術の変化を越えて可搬になります。いくつもの世代のフレームワークより長生きする長寿命の政府と企業のシステムにとって、決定的な利点です。

トレードオフ: 長所と短所

スタイル	最適な場合	長所	短所
モジュラーモノリス	ほとんどのシステム、特に初期	単純な運用、容易なトランザクションとリファクタリング	単一のデプロイ単位。一つとしてスケールする。浸食のリスク
マイクロサービス	多くのチーム、高いスケール、成熟したプラットフォーム	独立したデプロイ/スケール、障害の隔離	分散の複雑さ、データの一貫性、高い運用コスト
イベント駆動 / CQRS / イベントソーシング	非同期のワークフロー、監査のニーズ、異なる読み書き	疎結合、監査可能性、スケーラブルな読み取り	結果整合性、イベントのバージョニング、デバッグが難しい
サーバーレス	急増する、あるいはベースラインの低い、イベント駆動の仕事	サーバー管理なし、ゼロまでスケール、従量課金	コールドスタート、制限、ロックイン、高い定常負荷でのコスト

繰り返されるテーマは、運用的で認知的な複雑さと引き換えに、柔軟性と独立性を買うということです。分散型とイベント駆動のスタイルは、単一のコールスタックと単一のトランザクションの単純さを、独立してスケールし、デプロイし、失敗する能力と引き換えに手放します。その取引は、規模があり成熟したプラットフォームがあれば見返りをもたらします。それがなければ、破滅的です。内部の規律(ヘキサゴナル/クリーン)は、ほとんど常に価値があります。コストがほとんどかからず、後でスタイルを変える選択肢を開いたままにするからです。

チームで議論すべき問い

次のサービスを分割する前に、それを所有するチームも分割しますか。そして、その権限を持つのは誰ですか。 コンウェイの法則は、サービスの境界が実のところチームの境界であることを意味するので、組織図が支えない分割は、分散モノリスを生みます。二つのデプロイ可能なもの、一つのリリース列車、共有のオンコール。大きな企業では、チームを再編する権限は通常、報告ラインや財務や人事とともに、エンジニアリングの上にあり、だからアーキテクチャと組織設計は一緒に決めなければなりません。議論に証拠を持ち込んでください。提案されたサービスには、端から端まで所有でき、独自のオンコールを人員配置でき、独自の周期でデプロイできるチームがありますか。答えがノーなら、チームに資金を出すか、機能をモノリスのモジュールとして保ちます。オーナーシップを分割せずにコードを分割することは、分散のあらゆるコストを買い、独立性は何も買いません。
今日、各サービスを独立してデプロイできますか。それとも、密かに足並みを揃えて出荷していますか。 分散モノリスは、本章で最悪の結果です。ネットワーク呼び出し、部分的な失敗、サービス間のデータの一貫性に支払いながら、それでも他を伴わずに一つをリリースできません。兆候は、共有のデータベース、協調したアップグレードを強いる共有ライブラリ、資産全体を一緒に走らせなければならない統合テストです。大きなチームにとって、これは静かにスループットに上限を課します。図が独立性を示していても、すべてのチームが一つのリリースの後ろに並ぶからです。最近の変更を一つ取り、それを安全にするために、いくつのサービスが一緒にデプロイされなければならなかったか数えてください。単一の機能に触れた変更でその数が一より大きいなら、境界が間違っています。直し方は通常、サービスを増やすことではなく、各サービスに自分のデータと安定した、バージョン管理された契約を与えることです。
既存のサービスの分割のうち、見返りがなくなったものはどれで、戻して統合しますか。 本章の最も高度な習慣は、スタイルの決定を可逆なものとして扱うことです。ドライバーが現れたら取り出し、ドライバーが消えたら再びマージする。ほとんどの組織は分割しかしないので、各サービスの仕事を、オーケストレーションとネットワークのオーバーヘッドが小さく見せるまで、ナノサービスとおしゃべりなエンティティサービスが積み上がります。いつも一緒にデプロイされるもの、ビジネス機能ではなくデータベースのテーブルが理由で存在するもの、ネットワークの跳躍がリクエストのレイテンシを支配するようになったものを探してください。人員と予算が精査される企業や政府の資産では、二つの薄いサービスを一つの粗粒度のサービスに戻すことは、失敗の自認ではなく、正当なコスト削減の動きです。再統合を、取り出しと同じくらい公然とテーブルに載せ、両方を同じ証拠で決めてください。
プラットフォームとオンコールの成熟度は、提案しているスタイルを実際に支えていますか。そしてコミットする前に、具体的なギャップを名指しできますか。マイクロサービス、メッシュ、イベント駆動のバックボーンは、成熟したCI/CD、分散トレーシング、サービスディスカバリ、部分的な失敗を推論できるオンコールの文化の上にのってのみ、利益を届けます。大きな組織は、アーキテクチャのフォーラムで目標のスタイルを決めて、数十のサービスがすでに本番にあり、すべてのインシデントの診断に何時間もかかるようになってから、欠けているプラットフォームを発見しがちです。独立したデプロイとスケーリングの魅力を、午前3時に誰が運用するのかという冷静な問いと量ってください。チームを並行して出荷できるようにする同じ分割が、各チームが理解しなければならない失敗モードも増やします。議論に誠実な一覧を持ち込んでください。現在のデプロイ頻度、平均復旧時間、サービスの境界をまたぐトレーシングがあるか、一つのチームが現実的に運用できるサービスの数。企業や政府の設定では、欠けているプラットフォーム機能の調達と採用のリードタイムを加えてください。資金を出していないメッシュとプラットフォームチームを前提とするスタイルは、支えられない資産を運用する計画だからです。
ドメインのどの部分で、完全なイベントソーシングの監査証跡が便利さではなく法的な必要性であり、それを決める権限は誰にありますか。 イベントソーシングとCQRSは、完璧で再構成可能な履歴と、独自にスケールする読み取りモデルを買いますが、システムの寿命にわたって、イベントのバージョニング、プロジェクションの再構築、結果整合性についての推論のコストがかかります。監査証跡を必要としなかったドメインに適用すれば、その複雑さは純粋な税で、「この値にどう至ったか」が法的な問いであるドメインから取り上げれば、その不在はコンプライアンスの失敗です。相反する考慮は、一方に監査可能性とクエリのスケーラビリティ、もう一方にデバッグの難しさと開発者の認知負荷があるので、決定は、パターンに最も熱心な人ではなく、規制上の義務と運用上の負担の両方を理解する人々に属します。特定の法的または契約上の保持と再構成の要件、予想されるイベントの量、バージョニングとプロジェクションの作業の誠実な見積りを持ち込んでください。何年も後に決定を再構成することが法定の義務になりうる金融、税、政府では、ある境界付けられたコンテキストが不変のイベントログを必要とするか、しないかを承認する責任者を名指ししてください。
モジュラーモノリスが浸食されないようにして、後の取り出しを安く保つにはどうし、何が境界を徹底しますか。 モジュラーモノリスから始めることの根拠全体は、きれいな内部の境界が、後のサービスの取り出しを手頃にするという約束に拠っていますが、締め切りが一つのモジュールを別のモジュールのデータに手を伸ばさせたくなる瞬間、それらの境界は静かに崩れます。多くの貢献者を持つ大きなチームでは、善意とコードレビューだけでは線を守れません。徹底する仕組みがなければ、モノリスは静かに、そのスタイルが避けるはずだったビッグボールオブマッドになります。徹底された依存ルールとモジュールのインターフェースの摩擦を、何年も後に、どの境界も本物でなく、あらゆる取り出しが共有状態を解きほぐすことを意味すると発見するコストと量ってください。証拠を持ち込んでください。モジュールの境界は、ビルドツール、静的解析、パッケージ構造によって徹底されていますか。それとも、直近六回のマージが無視した、文書化された規約にすぎませんか。厳格な変更管理と数世代のフレームワークを生き延びなければならない長寿命の企業や政府のシステムでは、境界の徹底を監査可能な統制として扱い、後で分散する選択肢が、まだ持っていると想定するものではなく、実際に保ってきたものになるようにします。

セクター別の視点

スタートアップ。 単一のモジュラーモノリスを既定とし、マイクロサービスへの引力に抵抗してください。最も乏しい資源はエンジニアリングの注意で、サービスの群れは、プロダクトマーケットフィットの前には負担できない運用の税だからです。後で取り出せるよう、きれいなモジュール境界を保ち、スケールゼロと従量課金が、急増する、ベースラインの低い負荷に合う所でサーバーレスに手を伸ばします。具体的なドライバーが現れたときにだけ、一つだけを分割し、バーストする通知の送信者のような、決してそれより早くはしません。

小規模事業者。 プラットフォームチームはおらず予算も厳しいので、マネージドなプラットフォーム上のモノリスか少数の粗粒度のサービスを好み、メッシュ、トレーシング、サービスディスカバリを自分で築くのではなく、ホスト型のインフラを買ってください。サーバーをまったく運用しないで済む方法として、サーバーレスとマネージドデータベースを量り、担う人のいない運用負担を伴う分散設計に用心します。正しいアーキテクチャは、一人か二人が実際にデプロイし、観察し、復旧できるものです。

大企業。 本当の問題は、多くのチームとコンウェイの法則です。粗粒度のサービスを境界付けられたコンテキストとチームのオーナーシップに合わせ、分散を安全にするプラットフォーム(CI/CD、トレーシング、メッシュ、サービスディスカバリ)に意図して投資します。グループが再発明するのをやめるよう、ゲートウェイ、BFF、内部のクリーンアーキテクチャのパターンを標準化し、取り出しと再統合を、局所的な好みではなく、証拠に基づくポートフォリオの決定として統治します。すべての分割の運用コストを明示的に予算化してください。あなたの規模では、分散モノリスの失敗は高価で、解きほぐすのが遅いからです。

政府。 長いシステムの寿命、厳格な変更管理、調達のサイクル、監査可能性が選択を形づくります。ベンダーとフレームワークの世代より長持ちする、明示的で検査可能な境界と持続的な契約を持つスタイルを好みます。イベントソーシングは、市民向けの決定を再構成することが法定の義務である所でその複雑さを稼ぐので、中核の元帳に意図して使い、予算ごとに変わるルールを隔離するために、あらゆるサービスの内側でクリーンアーキテクチャを保ちます。独自のサーバーレスやベンダープラットフォームからの可搬性と出口を、後付けではなく調達要件として扱います。

事例

スタートアップ。 スケジューリング製品を作る4人のスタートアップは、競合がブログに書いたからマイクロサービスで始める圧力を感じますが、抵抗します。内部の境界が明確な単一のモジュラーモノリス(スケジューリング、課金、通知)を、一つのデプロイ可能なものの別々のモジュールとして出荷するので、一人のエンジニアがローカルで全体を動かせ、リリースは一回のプッシュです。製品が勢いを得るにつれて、バーストする負荷のもとでメールとSMSに展開する通知の送信者だけが、独自のサービスに取り出されます。まだプロダクトマーケットフィットを探している間は、十数個のサービスの運用の税を一切引き継ぎません。

大企業。 大手のeコマース会社は、モジュラーモノリスとして始まります。トラフィックが増えチームが増えるにつれて、最も負荷が高く最も独立して進化するドメイン(カタログ、カート、チェックアウト、検索)を、それぞれが自分のデータを所有する別々のサービスに取り出します。チェックアウトは、在庫、フルフィルメント、分析が消費するイベントを、イベントのバックボーンを通じて発するので、新しい消費者(不正検知、ロイヤルティ)が、チェックアウトに触れずに接続できます。APIゲートウェイが認証とレート制限を扱い、BFFがモバイル向けにペイロードを調整します。残りのトラフィックの少ないドメインはモノリスに残り、不要な断片化を避けます。

政府。 税務当局が、課税者の負債へのあらゆる変更が何年も再構成可能で法的に監査可能でなければならないので、中核の元帳のイベントソーシングの上に査定プラットフォームを築きます。コマンド(申告を提出する、支払いを適用する、調整を発行する)は不変のイベントを生み、読み取りモデルが現在の残高を職員と市民のために投影します。CQRSにより、公共向けのクエリ側は、書き込み側を危険にさらさずに、申告のピーク期のために独自にスケールできます。内部では、各サービスがクリーンアーキテクチャに従うので、予算ごとに変わる査定のルールが、永続化とメッセージングの技術から隔離されたままです。

ビジネスケース: 動機、ROI、TCO

スタイルの選択にかかるお金は莫大です。決定を元に戻すのが高くつくからです。マイクロサービスを早すぎる時期に採用すれば、プラットフォームの構築、重複するインフラ、分散したデバッグ、より重い運用の負担を通じて総所有コストを膨らませ、そのコストはシステムの寿命とともにあり続けます。本当に過負荷なモノリスの分割を拒めば、デリバリーのスループットに上限を課します。チームは共有のリリースの後ろに並び、あらゆる変更がシステム全体を危険にさらします。ROIの会話は、実のところ、運用への支出を組織のニーズに合わせることです。

リーダーシップには、技術ではなくスループットとリスクで論拠を示してください。独立したデプロイ可能性は、並行して出荷するチームが増え、リードタイムが短くなることを意味します。測定可能なビジネスの速度です。障害の隔離は、全体の障害が減り、影響範囲が小さくなることを意味します。測定可能な可用性と評判の保護です。しかし各スタイルが要求するプラットフォームへの投資についても同じくらい誠実であってください。メッシュ、トレーシング、CI/CDの成熟度は、任意の追加ではなく前提条件で、そのコストはTCOに属します。多くの組織にとって最も安い道は、今はよくモジュール化されたモノリスで、後の取り出しを安くするきれいな内部の境界を持つことです。それが、必要になる前に支払わずに、分散する選択肢を買います。

アンチパターンと落とし穴

分散モノリス。 一緒にデプロイされなければならず、データベースを共有するサービス。分散のあらゆるコストがあり、独立性はありません。
ナノサービス。 オーケストレーションとネットワークのオーバーヘッドが、仕事を小さく見せるほど細粒度のサービス。
プラットフォームのないマイクロサービス。 CI/CD、トレーシング、オンコールの成熟度の前に分割すること。失敗モードが増えます。
エンティティサービス。 ビジネス機能ではなく、データベースのテーブル(「ユーザーサービス」「注文サービス」)で分割し、あらゆる操作にサービス間のおしゃべりな呼び出しを強いること。
どこでもイベントソーシング。 監査証跡を必要としないドメインに適用し、利益なしに複雑さの税を払うこと。
モノリスとしてのゲートウェイ。 APIゲートウェイにビジネスロジックを置き、中央の隘路を再び作ること。
フレームワークに結合した中核。 ビジネスロジックがウェブやORM(オブジェクトリレーショナルマッピング)のフレームワークと絡み、テストも技術の変更も苦痛にすること。

成熟度モデル

レベル1: 開始。 スタイルは流行や偶然で選ばれます。一つの絡まったモノリスか、偶然の分散した混乱があり、境界はドメインではなく技術的な層や歴史に従い、分割は何かが壊れたときに反応的に起こります。
レベル2: 発展。 一部のチームは、モノリスの内部に意図したモジュール境界を引くか、少数の粗粒度のサービスを立ち上げ、一部の横断的関心事は一貫して扱われます。実践は不均一で、あるグループはサービスを境界付けられたコンテキストに合わせ、別のグループはまだデータベースのテーブルで分割し、取り出しは場当たり的なままです。
レベル3: 標準化。 文書化されたアプローチが組織全体で徹底されています。サービスは境界付けられたコンテキストに合わせられて自分のデータを所有し、ゲートウェイとBFFのパターンは適切な所で使われ、内部のクリーンまたはヘキサゴナルの層構造が標準で、すべての分割に述べられたドライバーが必要です。モジュールの境界は、規約だけでなく、ツールで徹底されます。
レベル4: 管理。 スタイルの決定が、ベースラインに対して測定され、制御されます。サービスごとのデプロイ頻度とリードタイム、平均復旧時間、典型的な変更のために一緒にデプロイされなければならないサービスの数、ネットワークの跳躍のレイテンシを追跡し、各分割のコストを、それが買うはずだった独立性と比べます。境界が生き残るかは、好みではなく証拠が決め、分散モノリスへのずれは、障害ではなく指標で捉えられます。
レベル5: オーケストレーション。 アーキテクチャは組織設計と統合され、継続的に適応されます。成熟したプラットフォーム(CI/CD、トレーシング、必要な所でのメッシュ)が、分散と再統合の両方を安くし、チームは、ドライバーが現れたときに日常的に取り出し、消えたときにサービスを戻して畳み、スタイルの選択は、チームのトポロジー、負荷、リスクの状況の変化に応じて資産全体で再均衡されます。

議論のためのアイデア

システムのどこで、モノリスが実際に強みで、どこで本物のボトルネックですか。
次のサービスを取り出すことを正当化する具体的なドライバーは何で、作る前にそれを名指しできますか。
あなたの組織は、マイクロサービスが要求する運用の成熟度を持っていますか。何が欠けていますか。
ドメインのどの部分で、完全なイベントソーシングの監査証跡が、あれば嬉しいものではなく、法的またはビジネス上の必要性ですか。
現在のサービスの境界は、チームの境界をどれだけ反映していて、その整合は助けになっていますか、害になっていますか。
来年ウェブフレームワークやデータベースを変えなければならないとしたら、ビジネスロジックのどれだけを書き直さなければなりませんか。

要点

アーキテクチャスタイルを、流行ではなく、本物の力(チームの規模、ドメイン、負荷、運用の成熟度)から選びます。
モジュラーモノリスはほとんどのシステムにとって正しい既定です。具体的なドライバーがあるときにだけ、境界付けられたコンテキストの線に沿ってサービスを取り出します。
マイクロサービスは、運用的で認知的な複雑さを、独立したデプロイ、スケーリング、障害の隔離と交換します。成熟したプラットフォームが必要です。
イベント駆動、CQRS、イベントソーシングは、結果整合性とバージョニングの複雑さと引き換えに、疎結合と監査可能性を提供します。意図して採用します。
ゲートウェイ、BFF、メッシュは多数のサービスの資産を手なずけますが、重さを加えます。規模が求めるときに導入し、その前にはしません。
あらゆるサービスの内側にヘキサゴナル/クリーンアーキテクチャを適用し、価値あるビジネスロジックを、技術の変化を越えてテスト可能で持続的に保ちます。

参考文献とさらなる読み物

Sam Newman, Building Microservices and Monolith to Microservices
Chris Richardson, Microservices Patterns
Eric Evans, Domain-Driven Design
Vaughn Vernon, Implementing Domain-Driven Design
Robert C. Martin, Clean Architecture
Alistair Cockburn, “Hexagonal Architecture (Ports and Adapters)”
Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns
Martin Fowler, Patterns of Enterprise Application Architecture (and articles on CQRS and Event Sourcing)
Matthew Skelton and Manuel Pais, Team Topologies