【ITニュース解説】Wolverine + Marten: My story and subjective take

長らく従来の.NET開発手法、具体的にはEntity Framework Core（EF Core）やDapperといったORM、そしてControllerベースのWeb API構築に慣れ親しんできた開発者が、WolverineとMartenという新しい技術スタックへ移行した経験と、その中で得た知見を共有する記事の内容を解説する。彼の個人的な体験と学びは、新しい技術の導入を検討している開発者、特にシステムエンジニアを目指す初心者にとって、貴重な洞察となるだろう。

従来の.NET Web API開発では、HTTPリクエストを処理するControllerを中心にアプリケーションを構築するのが一般的であった。商品作成リクエストをProductsControllerが受け取り、サービス層を呼び出して処理を行うといった流れである。このアプローチは広く普及し、多くの開発者にとって馴染み深い。

しかし、WolverineとMartenは、この従来の開発スタイルとは異なる、よりイベント駆動型でドメイン駆動設計（DDD）に特化したアプローチを提供する。 MartenはPostgreSQL上に構築されたドキュメントデータベース兼イベントストアである。.NETアプリケーションからPostgreSQLをリレーショナルデータベースとしても、JSONドキュメントを直接扱えるドキュメントデータベースとしても柔軟に利用できる。従来のORMでは扱いにくいデータ構造やイベント履歴管理に有効だ。Wolverineはメッセージングフレームワークで、アプリケーション内の「コマンド」（指示）や「クエリ」（要求）の処理を専門に担う。Martenのイベントソーシング機能と連携し、ビジネスの出来事をイベントとして捉えるイベント駆動型アプリケーションの構築を支援する。この組み合わせにより、イベント駆動型でドメイン駆動設計（DDD）を取り入れたアプリケーションを効率的に構築できる。

記事の筆者は、Wolverineの導入において初期に誤った使い方をしてしまった経験を語っている。それは、Wolverineを単にMediatRのようなメディエーターパターン（アプリケーション内の異なるコンポーネント間の通信を仲介し、依存関係を減らすための設計パターン）の代替として利用することだった。この「中途半端なアプローチ」では、学習コストだけがかかり、WolverineとMarten本来のイベントソーシングやDDDとの連携といった利点が得られない。従来のControllerよりも複雑になり、チームの混乱を招くだけであったと指摘する。Wolverineの真価を引き出すには、その「フルスタック」なアプローチを全面的に受け入れる必要がある。

そのフルスタックなアプローチとは、主に以下の三つの要素から成る。 第一に、「集約駆動設計（Aggregate-Driven Design）」である。これは、ビジネスロジックとデータの一貫性を保つ単位を「集約（Aggregate）」として定義する考え方だ。例えば「商品」が集約であれば、その集約が自身の操作（名前変更など）を行い、結果として「イベント」（例：ProductCreated）という形でビジネス上の出来事を記録する。これらのイベントは変更履歴としてMartenに保存される。 第二に、「コマンドハンドラ」の活用である。外部からのリクエストである「コマンド」は、適切な「コマンドハンドラ」によって処理される。ハンドラは集約を呼び出し、ビジネスロジックを実行させ、結果発生したイベントをMartenに保存する。Wolverineはコマンドハンドラを直接HTTPエンドポイントに紐付ける機能も持ち、Controllerの記述を省略できる。 第三に、「イベント駆動型プロジェクション」である。イベントソーシングではデータの変更履歴であるイベントが全て保存されるが、ユーザーインターフェース（UI）で表示するデータは、通常、それらのイベントから集約された現在の状態を簡潔に表現したものになる。プロジェクションは、Martenに保存されたイベントを購読し、UIの表示ニーズに最適化された「読み取りモデル」（例：ProductSummary）を構築・保存する。これにより、UIは集約から直接データを取得するのではなく、整形された読み取りモデルから高速にデータを取得できる。

このWolverineとMartenのフルスタックなアプローチを採用することで、筆者は自身のコードベースが約30%削減されたと実感している。これは、個別のデータ転送オブジェクト（DTO）作成やエンティティとDTO間のマッピング、複雑なリポジトリパターン、手動の変更追跡などが不要になるためである。開発者はビジネスロジックに集中できる。

WolverineとMartenを効果的に導入するための重要なポイントがいくつか提示されている。まず「小さく始めること」だ。プロジェクト全体を一度に書き換えるのではなく、特定のビジネス領域（境界コンテキスト）から段階的に移行し、リスクを抑えながら学習を進める。次に「学習への投資」が不可欠である。コードのコピペだけでは不十分で、ドキュメントを読み込み、DDDの概念をチーム全体で深く理解することが鍵となる。また「イベントを受け入れる」という考え方の転換も重要だ。従来のCRUD思考から離れ、「商品が作成された」といったビジネス上の出来事を「イベント」として捉える思考への転換が求められる。さらに「プロジェクションを賢く使う」こと。UIのニーズに合わせて最適な読み取りモデルを作成し、一つのプロジェクションで全ての表示要件を満たそうとせず、柔軟なアプローチが必要だ。最後に、MartenはPostgreSQLを基盤とするため、単なるドキュメントDBとしてだけでなく、PostgreSQLの強力なリレーショナル機能も最大限に活用できることを理解すべきだ。

筆者は数週間の学習で、ジュニア開発者を含むチームの機能開発がスムーズになったと実感している。当初はMartenがEF Coreの単なる再発明ではないか、非Microsoft製ライブラリへの依存リスク、学習曲線の高さなどを懸念していたが、MartenのハイブリッドなアプローチがEF Coreでは複雑になりがちなイベントソーシングやプロジェクションの課題を自然に解決することに気づいた。プロジェクトの活発なメンテナンスとコミュニティの存在、そしてPostgreSQLへのデータ保持により、リスクも払拭された。チームの学習曲線も、集約やイベントの基本を理解すれば、フレームワークが多くの処理を担うため予想以上にスムーズであった。

結論として、WolverineとMartenは全ての開発に適するわけではないが、イベント駆動型でビジネスロジックが豊富なアプリケーションには検討する価値がある。成功の鍵はコミットメントにあり、Wolverineを単なるメディエーター代替として使うのではなく、集約駆動の考え方、イベント中心の思考、PostgreSQLの強力な機能を全面的に活用することだ。小さな概念実証から始め、ドキュメントを読み込み、従来の開発手法からの「マインドセットの転換」に取り組むことが、この技術スタックを使いこなす最善のアドバイスとなる。