純粋なイミュータブルモデルを設計 してからイベントソーシングと組み 合わせるDeciderの実践方法の紹介 株式会社ジェイテックジャパン 高丘 知央 2026年1月10日(土曜日) CQRS+ES カンファレンス 福岡 2026 #cqrs_es_con 

自己紹介 高丘 知央 - Tomohisa Takaoka X: @tomohisa GitHub: @tomohisa 福岡出身です！: 98年に久留米高専卒業、博多のソフトウェア開発 会社で数年働いていました。 Works at: 株式会社ジェイテックジャパン、J-Tech Creations, Inc. JTS Group - 株式会社ジャパンテクニカルソフトウェア 品川 CTO: 中小企業の受託開発をモダンな開発スタイルで。イベントソ ーシング、CQRSなどのソフトウェアアーキテクチャに関するコン サル業務 Microsoft MVP for Developer Technologies from Nov 2024- OSS: Sekiban - Event Sourcing and CQRS Framework. 2 / 34 

本日のアジェンダ 1. ジェイテックのイベントソーシング活動 2. イベントソーシング+CQRS所感 3. Deciderパターンの紹介 4. Dynamic Consistency Boundary半年使っての所感 5. Sekibanでの実装・運用について 6. Sekibanのこれから 3 / 34 

1. ジェイテックの イベントソーシング活動 4 / 34 

1-1. Sekibanの歴史 DDD導入からの道のり 年月 出来事 2019年 DDD導入。戦略的DDDのみで、トランザクションによるパフォーマンス課 題 2022年4 月 @tkawaeさんと新アーキテクチャ協議、イベントソーシングを知る。社内 開発開始 2022年10 月 社内版 Sekiban.Core で顧客プロジェクト開始 2023年12 月 オープンソース版 Sekiban.Core リリース、サーバースケールアウト時の動 作に心配あり 5 / 34 

1-2. Sekibanの進化 アクターモデルへの移行 年月 出来事 2024年12月 CQRS+ES カンファレンスで登壇 2025年1月 アクターモデル版開発開始 2025年2月 Sekiban.Pure（OrleansのActorを活用）を開発 2025年3月 #イベントソーシング勉強会 第1回開催 2025年4月 Sekiban.Pure.Dapr（Daprアクターモデル版）開発 6 / 34 

1-3. DCBへの挑戦 Dynamic Consistency Boundaryの採用 年月 出来事 2025年7月 Sekiban.ts 開発（Sekiban.Pureベース、Dapr対応） 2025年7月 #イベントソーシング勉強会 第3回で @tkawae がDCBについて発表 2025年8月 Sekiban.Dcb 開発開始、簡易版完成 2025年9月 2つの顧客プロジェクトでSekiban.Dcbの採用を決定 2026年1月 CQRS+ES カンファレンス登壇（今日！） 7 / 34 

2. イベントソーシング+CQRS所感 8 / 34 

2-1. AIコーディングとデータ管理 AIコーディングにおいて、追記型のデータ管理は必須 データを追記で管理できる: 削除は基本的に論理削除 修復の可能性: 大変だが、データを消していなければ修復可能 純粋イミュータブルモデル: 純粋関数で管理できるコードのガードレー ルが必要 GIGO原則の適用: Garbage in, Garbage out（ゴミを入れればゴミが出 る）- 質の低い入力データからは質の低い出力しか得られない。イベン トソーシングで意味のあるデータを保存することで、AIに高品質な入 力を提供できる LLMに与えるガードレールの設計が品質を左右 LLMが多くのコードを参照せずにモデルの設計に集中できる 純粋なインメモリのデータモデルと関数でまずドメインを設計 それをイベントソーシングフレームワークに載せる 基本的現行コードを真似させる 9 / 34 

Actor 1 State Execution Queue DB Transaction Actor 2 State Execution Queue DB Transaction User 1 User 3 User 2 Message Message 2-2. アクターモデル1年の運用 スケールアウト時の挙動についての心配 が激減 アクターモデルを使い始めて約1年 スケールアウト時の挙動についての心配が少なく稼 働 鍵となるのは: スケールアウトしないときにどれだ け小さく運用できるか 運用コストの現実 個人サイト: AzureのマネージドサービスAppService などで月額5,000円程度で運用開始可能 企業向け: Azure Container Appsなどでローリング アップデートを活用する構成 10 / 34 

3. Deciderパターンの紹介 11 / 34 

3-1. Deciderパターンとは "Functional Event Sourcing - Decider" by Jérémie Chassaing 「関数型イベントソーシングとそのメイン パターンであるDecider」 「関数型コアをモデルに適用することで、 もう少し先に進むことができます。アイデ アは、サブシステムを純粋関数として書く ことです。 」 参照: https://thinkbeforecoding.com/post/2021/12/17 /functional-event-sourcing-decider 12 / 34 

3-2. Deciderの本質 Decider 関数とは 「要約すると、Decider 関数は以下を書く 方法です：特定の状態でこのコマンドを処 理するよう求められたとき、イベントとし て表現される何が起こるか。 」 インフラからの独立 「Deciderを実行するために書いたすべての インフラストラクチャコードが、実際のド メインコードとは完全に無関係であること に気づいたかもしれません。 」 「ドメインコードをDeciderとして書くこと ができ、永続性の種類を後で選択できま す。 」 13 / 34 

3-3. EvolveとDecide 2つの核心的な関数 Evolve（進化） State + Event = State (version++) 別名: Aggregate (Tag) Projector イベントが状態をどのように変えるかを定義 Decide（決定） Command + State = Event 別名: コマンドハンドラー コマンドに対してどのイベントを発行するかを決定 14 / 34 

3-4. SekibanでのDecider実装 ImmutableModelsプロジェクトに純粋なロジックを集約 Sekibanでは、EvolveとDecideの中でシンプルにできる判断を純粋関数でできる機能にまとめ、 ImmutableModelsプロジェクトに集約 Deciderをコマンドごとに定義 そのイベントによって、StateをどのようにEvolveするか そのイベントを登録するためのValidate条件を純粋関数で記述 こうすることで、コマンドさえ考えずにImmutableModelsの中でドメインロジックに集中できる 15 / 34 

UnregisteredBook （未登録本） イミュータブルモデル イミュータブルモデルプロジェクト AvailableBook （貸出可能本） CheckedOutBook （貸出中） イベントソース プロジェクト 登録コマンド 書籍登録イベン ト 貸出コマンド 書籍貸出イベ ント 返却コマンド 書籍返却イベン ト 本の 登録 モデル 変換関数 本の 貸出 モデル 変換 関数 本の 返却 モデル 変換 関数 変換関数 コマンド イベント & タグ Pure C# 本A タグ 太郎さんタグ 本A タグ 太郎さんタグ 本A タグ 3-5. ImmutableModelsの 構成要素① コマンドを考えずに設計できる要素 （Immutable Models） Events: ビジネスで起きた事実 States: 集約の現在の状態 Tags (DCB): Dynamic Consistency Boundary のタグ Event の Decider (static methods class) Validate: イベントを追加する条件 Evolve: イベントがStateをどう変えるか 16 / 34 

UnregisteredBook （未登録本） イミュータブルモデル イミュータブルモデルプロジェクト AvailableBook （貸出可能本） CheckedOutBook （貸出中） イベントソース プロジェクト 登録コマンド 書籍登録イベント 貸出コマンド 書籍貸出イベント 返却コマンド 書籍返却イベント 本の 登録 モデル 変換関数 本の 貸出 モデル 変換 関数 本の 返却 モデル 変換 関数 変換関数 コマンド イベント & タグ Pure C# 本A タグ 太郎さんタグ 本A タグ 太郎さんタグ 本A タグ リードモデル + クエリ 本リスト 貸出中リスト 利⽤者リスト 棚リスト 3-5. ImmutableModelsの 構成要素② コア機能を利用してイベントソーシ ング実装を作成する Aggregate Projection: Evolveを使用 Command Handler: Validateでチェックして から、AppendEvent Readmodel Projection: 読み込みモデルはリ スト表示のために必要に応じて作る 17 / 34 

3-6. 設計原則 Always Valid Domain Model、Null を使わない設計 Discriminated Union + Switchを多用 C#でのDiscriminated Unionは完全性のチェ ックができない 1個追加した時に全てのswitchでエラーが出ない しかし問題は基本的にそれだけ シリアライズ・デシリアライズ 形を使って、使える機能判断ができる サンプルテンプレートはnugetからダウンロ ード可能 18 / 34 

4. Dynamic Consistency Boundary半年の所感 19 / 34 

クラスA 作成イベント クラスA 集約 佐藤さん⼊学イベント 佐藤さん集約 佐藤さんをクラスに登録 佐藤さんをクラスに登録 集約ベースのイベントソーシング 集約を超えたイベントは登録できないので、同じ意味のイベントを複数の集 約、パーティションを分けたデータ領域に登録する クラスA タグ 佐藤さんタグ 佐藤さんをクラスに登録 動的⼀貫性境界(DCB) のイベントソーシング イベントに動的にタグを紐づけて、紐づけたタグ両⽅の⼀貫性を確認してか らイベントを発⾏することができる。この例ではクラスタグと、佐藤さんタ グ両⽅の⼀貫性を確認してからイベントを保存する 佐藤さん⼊学イベント クラスA 作成イベント 4-1. DCBは集約を否定するもの ではない "Kill the Aggregate"というほどではな い 基本的には、集約に対するイベントの蓄積とプロジ ェクションを考える イベントソーシングの基本概念は変わらない DCBの本質的な違い 1イベントで複数の集約のProjectionに影響を及ぼ せる イベントの設計がシンプルになる まず、ビジネスで起きた事実をモデリングし、その 後、どの集約に影響を及ぼすかを考える イベント名に集約情報を含めなくてよくなるので、 設計しやすい 20 / 34 

4-2. パフォーマンスと設計の考慮 巨大な一貫性境界(トランザクション)は避ける 1イベントで100タグなどでConsistencyチェックを始めると... 巨大なトランザクションと同じ パフォーマンスも出ない まずコマンドが成功しなくなる 継続して重要なこと パフォーマンスを考えたタグ、イベント設計は引き続き重要 DCBを採用しても、設計の基本原則は変わらない 21 / 34 

4-3. DCB採用の判断基準 Saga、Process Managerとの比較 DCBを使わなくても、Saga・Process Managerで複数集約の一貫性担保は可能 DCB採用のメリット イベントソーシングフレームワークでSagaの機能を受け持つ コードがシンプルになるのであれば採用の価値あり 我々の判断 2つの顧客プロジェクトでSekiban.Dcbの採用を決定 モデリングのシンプルさが決め手 22 / 34 

5. Sekibanでの 実装・運用について 23 / 34 

5-1. IaCで簡単デプロイ Azure中心のデプロイ構成 C# + Orleansなので、Azureへのデプロイが一番スムーズ AWSにもデプロイできる構成だが、現時点ではAzureがメイン Bicep + az loginで簡単にデプロイできる構成 デプロイ先の選択肢 個人・小規模: Azure App Service（月額5,000円程度〜） 企業向け: Azure Container Apps（ローリングアップデート対応） dnx CreateSekibanTemplate で簡単テンプレート作成！ .NET SDKさえ入っていればワンライナー 24 / 34 

5-2. ライブプロジェクションの採用 現顧客のケース データ量が限られたビジネスシステム Readモデルはライブプロジェクションを採用 プロジェクションの実態 全イベントをプロジェクション 5万〜10万のイベントのプロジェクションで、約30MBのデータ それをアクターで持ち、クエリに対応 25 / 34 

5-3. アクターの永続化戦略 効率的な停止・起動 アクター停止時: toJson().toGzip() で約3MBのBlob Storageに保存 アクター再起動時: 読み込むことで復帰に10秒かからない マルチプロジェクターのバージョン管理 マルチプロジェクターもversionを持つ 作り直しが必要なときは起動時読み込みをスキップ 事前にCLIで新バージョンのマルチプロジェクションデータを保存 バージョンが変わっていても高速起動が可能 26 / 34 

5-4. Readモデルのアーキテクチャ 現状の構成 Readmodelが実現できるアーキテクチャ メッセージングシステムを導入済み 現時点ではRDBへのリードモデル展開のプロジェクトは行っていない 将来的な拡張 RDBへの展開も可能な設計 必要に応じてReadモデルの永続化先を選択可能 27 / 34 

5-5. AI対応のCLI開発 問題解決・調査のためのCLI データの接続文字列（Cosmos）を渡すと以下の機能を実行可能: タグ（集約）のリスト取得 タグ（集約）毎の全イベント取得、ファイル保存 タグ（集約）毎の任意のイベントバージョンか、日付時点でのState計算・出力 MultiProjectionのリスト取得 MultiProjectionを取得してファイル保存 AIデバッグとの連携 Claudeなど、AIに頼んでコードベースを元にデバッグを行うことができる 28 / 34 

6. Sekibanのこれから 29 / 34 

6-1. 今後の開発計画 Readmodelの強化 Readmodelを簡単に構築、廃棄、キャッチアップ、新規作成できるフレームワークを作りたい プラットフォーム拡張 Sekibanバックエンドのデプロイ as Serviceにトライしたい Typescript Sekiban Dcbを作ってみたい 30 / 34 

6-2. Actor Model as a Serviceへの対応 新しいインフラの登場 Azure Durable Functionsのインフラ Cloudflare Durable ObjectsなどのActor Model as a Service 対応計画 これらのActor Model as a Serviceに対応したSekibanも作りたい より低コストで、より簡単にイベントソーシングを始められる環境を目指す 31 / 34 

まとめ 本日お伝えしたこと 1. Deciderパターン: 純粋なイミュータブルモデルでドメインを設計し、イベントソー シングと組み合わせる 2. DCBの実践: 半年の運用でモデリングがシンプルになることを実感 3. Sekibanの現在: アクターモデル + ライブプロジェクション + AI対応CLI 4. AIとの協働: LLMに与えるガードレールとしての純粋関数設計 メッセージ 純粋なインメモリのデータモデルと関数で設計することで、LLMも開発者もドメインに集中できる 32 / 34 

参考文献・リソース 書籍・論文・ブログ Jérémie Chassaing "Functional Event Sourcing - Decider" (2021) https://thinkbeforecoding.com/post/2021/12/17/functional-event-sourcing-decider Dynamic Consistency Boundary: https://dcb.events Greg Young "Always Valid" (2009) Eric Evans DDD EU 2016 Talk ツール・フレームワーク Sekiban: https://github.com/j-tech-japan/sekiban Microsoft Orleans Dapr 33 / 34 

Thank you 株式会社ジェイテックジャパン https://www.jtechs.com/japan/ イベントソーシング・CQRSフレームワーク Sekiban https://github.com/j-tech-japan/sekiban Zenn - ジェイテックジャパンブログ https://zenn.dev/p/jtechjapan_pub