Modular Monolith Locally, Microservices in Production

Modular Monolith Locally, Microservices in Production JJUG CCC 2026 Spring シンプレクス株式会社 スポンサーセッション シンプレクス株式会社 小林 政友 / 長根尾 貴仁 © 2026 Simplex Inc.

自己紹介 小林政友 (2017年 新卒入社) •好きな言語など • Kotlin, 非同期処理 • チームメンバー全員が設計から開発まで携わること •これまでの経験 • メガバンク向け リスク管理システム開発 • 証券会社向け CFD取引システム開発 • 国民向けポータルアプリ フロントエンド開発 • 官公庁向けシステム アーキテクチャ策定 2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 1

自己紹介 長根尾 貴仁 (2019年 新卒入社) •好きな言語など • Kotlin、TypeScript • テスト自動化、アジャイル開発 •これまでの経験 • 暗号資産取引システム開発 • 暗号資産ウォレット管理システム開発 • 社会課題解決型web3ゲーム開発 2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 2

紹介 ブース出展しています！ • RoomK (展示会場2) の「コーヒー提供」の向かい側にてお待ちしています。 シンプレクスメンバーからの発表が2つあります！ • なぜJavaのジェネリクスには「PECS原則」が必要なのか？ – Scala/Kotlinと比較して理解するワイルドカードの設計思想 • 15:30–15:50 @Room M by 山田 耀平 • switch式で始めるJava流パターンマッチング • 15:55–16:15 @Room M by 伊藤 悠椰 (yuya296) 人材を募集しています！ • https://recruit.simplex.holdings/career/ • https://www.docswell.com/s/Simplex/KJQJNE-career_engineer 2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 3

• https://recruit.simplex.holdings/career/
• https://www.docswell.com/s/Simplex/KJQJNE-career_engineer

2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 4

2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 5

アジェンダ 「SDD」という開発アプローチ 1 設計と実装を分断せずシームレスにつなげる取り組みについて マルチコンテキストなDDD × マイクロサービス 2 業務を「区切られた文脈」で分割し、それをサービス境界として実装する方法について 高い開発者体験との両立の工夫 3 サービス境界を保ちつつ、開発者体験を損なわない方法について 2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 6

SDD: Smart Design & Development 1 2 3 設計と実装が分断されるほど、業務理解はコードから失われていく。 Smart Design & Development の略 SDD Spec Driven Developmentではありません！！ 「設計と実装の垣根を下げ、ビジネス価値創出に集中できる 開発」を目指すアプローチ 背景 SDD のゴール • 「業務担当者 → 要件書 → 設計書 → コード」という「翻訳の連鎖」で情報が失わ れていく • 設計書はすぐ古くなり、コードと乖離する • 「設計書の完成」が「コードの完成」をほぼ 意味する • 業務担当者とエンジニアが同じ言葉で業 務（モデル）を語れる 2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 7

SDD: Smart Design & Development 1 2 3 SDDでは、業務モデル・モジュール境界・依存方向を一体で設計し、コード上でも崩れない構造を作る。 モデル駆動開発 業務ドメインにおける「モデル」を定義し、モデルがビジネスロジックをカ プセル化した状態を目指す。 ビジネス関心指向による 意味的分割 データ指向・アーキテクチャ指向ではなく、ビジネスの関心領域を軸に モジュールとサービスを分割する。 設計と実装の シームレスな接続 業務理解・設計・実装を分断せず、モデルがそのままコードになる。 コードを読めばビジネス・設計が分かり、その逆も然り。 厳密な依存関係の遵守 モジュール間の依存方向をビルドレベルで強制し、境界が崩れない構 造を維持する。 ドメイン層は外部（フレームワーク・DBなど）に一切依存しない。 2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 8

複雑な業務は1つのモデルでは表せない 1 2 3 同じ言葉でも、業務の文脈が違えば意味もルールも変わる。 例：取引先顧客管理業務の場合 営業部門 契約部門 請求部門 顧客 = 「見込み客」 顧客 = 「契約者」 顧客 = 「請求先」 関心のある属性 関心のある属性 関心のある属性 ・商品への関心度 ・タッピング履歴 ・確度 ・関心のあるプラン ・与信枠 ・契約中のプラン ・請求先住所 ・支払方法 ・過去支払履歴 ☞ これらを1つの「顧客」として扱うと巨大な「神モデル」が爆誕する 2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 9

複雑な業務は1つのモデルでは表せない 1 2 3 1つの巨大なモデルに業務を押し込むと、変更・理解・テストのすべてが重くなる。 変更の影響が意図せぬ箇所に波及 認知負荷の増大 結果としてテスト範囲が膨大となる。毎度の リリースが怖くなることでアジリティも低下す る。 開発着手までのリードタイムや新メンバーの キャッチアップコスト増大、ナレッジの属人化。 チーム間のコミュニケーションコストの増大 ビジネスサイドの変更への追従が困難 他チームで追加した属性（フィールド）に怯 える日々。設計意図もわからず増えていく。 さまざまなロジックが一箇所に混在し、業務 要件に相当するコードを見つけ出すのが大 変。 2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 10

マルチコンテキストなDDD 1 2 3 Bounded Context (境界付けられたコンテキスト) ごとにモデルを分け、コンテキスト間はAPI/Eventで連携する。 営業コンテキスト 関心度 契約確度 顧客 タッピング履歴 API 契約コンテキスト 顧客 関心のあるプラン 契約中プラン Event 与信枠 請求コンテキスト 支払履歴 支払方法 顧客 請求先住所 API ☞ コンテキスト間はAPI/Eventで通信し、共有データを用いない。 2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 11

マルチコンテキストなDDD 1 2 3 コンテキストを分けるだけでなく、言葉・依存方向・変換責務を明確にする。 各コンテキストは独自の ユビキタス言語を持つ 現実世界で同じ実体だとしても、業務の文脈が異なればコンテキストも 異なるため、異なる名前・属性・振る舞いを持つべきである。システム上 の用語ではなく、なるべく業務上の呼称を踏襲すべきである。 ビジネス関心指向による 上流・下流を明確にし、逆流・循環を許容すべきではない。 意味的分割 システムの文脈では、API・APIクライアントの関係となる。 設計と実装の シームレスな接続 2026/05/30 他コンテキストのモデルはそのまま取り込まず、自コンテキストの言葉に 変換すべきである。（Hint: 腐敗防止層） Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 12

コンテキスト境界とサービス境界 1 2 3 Bounded Context（境界付けられたコンテキスト）はマイクロサービスの基本思想と対応する。 2026/05/30 Bounded Context マイクロサービス 業務ごとに独自のモデルを持つ サービスごとに独自のデータストアを持つ APIで通信 REST/gRPC/Eventで通信 業務ごとに独立して進化する 独立してデプロイできる 業務チーム単位で醸成される チーム単位で開発・運用できる （逆コンウェイの法則） Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 13

コンテキスト境界とサービス境界 1 2 3 業務境界とサービス境界が揃うと、変更・チーム・スケールの単位が揃う。 変更容易性 変更対象を業務コンテキスト内に局所化できる。 API/Eventの契約を保てば内部モデルや実装を独立して進化可能。 チームの自律性 各開発チームが自分のコンテキスト内で自由に設計・実装ができる。 公開しているAPIを変更しない限り他コンテキストに影響を及ぼさない。 スケーリングの 柔軟性 高負荷・ミッションクリティカルなサービスを狙って局所的にスケールアウト できる。 2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 14

マイクロサービスは開発者体験が伴わないことも 1 2 3 ただし、サービスを分けるほど、ローカル開発のフィードバックループは重くなりやすい。 User Service Order Service Market Service Payment Service pid=8001 pid=8002 pid=8003 pid=8004 JVM JVM JVM JVM 起動対象が多い デバッグが分断される リソースの逼迫 1機能の確認にも複数サービスの 起動が必要になる 処理がプロセスを跨ぎ、IDE上での トレースに一苦労することも 複数サービスの同時起動で、CPU ・メモリ・ポートを消費する 2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 15

アーキテクチャの整理 1 2 3 © 2026 Simplex Inc. 16 アーキテクチャ選択は、業務の複雑さ・境界の切り方・実行形態を分けて考えると整理しやすい。 モノリス 業務 サービス境界 (モジュール単位) 実行形態 (プロセス単位) 2026/05/30 簡単 モジュラーモノリス マイクロサービス それなりに難しい ～ 複雑 一塊 業務単位で分かれる (基本的に)1つ Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring 複数

アーキテクチャの選択 1 2 3 © 2026 Simplex Inc. 17 サービス境界は業務の都合で決める。では、実行形態は何で決めるべきか。 モノリス 業務 簡単 モジュラーモノリス マイクロサービス それなりに難しい ～ 複雑 実際はグラデーション サービス境界 (モジュール単位) 一塊 SDDの発想からも 業務単位で分かれる コンテキスト単位で モジュールを分割したい 実行形態 (プロセス単位) 2026/05/30 実行形態は 何が起因で決まるのか。 (基本的に)1つ Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring 複数

Modular Monolith or Microservices …？ 1 2 3 モジュラーモノリスとマイクロサービスを選ぶ理由を整理する。 共通 • 業務境界を表現したい • 変更影響を局所化したい • モデルの混在を避けたい • 依存関係を制御したい • チームの責任範囲を明確にしたい • コードベースを理解しやすくしたい • テスト範囲を絞りたい • 将来の分割・置き換えに備えたい • 技術的負債の拡散を防ぎたい • 業務の成長に耐えたい モジュラーモノリス マイクロサービス • デプロイ単位が単純 • ローカル開発が軽い • プロセス間通信を最適化したい • デバッグしやすい • 分散システムの複雑さを避けた • 初期開発速度を出しやすい い • 境界をコード上で育てられる • 運用監視の構成がシンプル • サービスごとにスケールできる • チームごとの自律性を高めやす • サービスごとに独立してデプロイ い できる • 技術選定の自由度が上がる • 障害の影響範囲を限定しやす い 2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 18

Modular Monolith or Microservices …？ 1 2 3 マイクロサービスを選んでも、開発者体験の良さは取り入れたい。 共通 • 業務境界を表現したい • 変更影響を局所化したい • モデルの混在を避けたい • 依存関係を制御したい • チームの責任範囲を明確にしたい • コードベースを理解しやすくしたい • テスト範囲を絞りたい • 将来の分割・置き換えに備えたい • 技術的負債の拡散を防ぎたい • 業務の成長に耐えたい モジュラーモノリス マイクロサービス • デプロイ単位が単純 • ローカル開発が軽い • プロセス間通信を最適化したい • デバッグしやすい • 分散システムの複雑さを避けた • 初期開発速度を出しやすい い • 境界をコード上で育てられる • 運用監視の構成がシンプル • サービスごとにスケールできる • チームごとの自律性を高めやす • サービスごとに独立してデプロイ い できる • 技術選定の自由度が上がる • 障害の影響範囲を限定しやす い モジュラーモノリス特有で 採用が難しい 2026/05/30 マイクロサービスでも 享受したいメリット アーキテクチャ上 特に大切にしたい Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring 部分的に 放棄するメリット © 2026 Simplex Inc. 19

Modular Monolith or Microservices …？ 1 2 3 守るべき境界と、許容するトレードオフを明確にする。 共通 業務境界・業務の依存関係、データの所有権、変更影響の局所化、サービスの責務、… • 業務境界を表現したい • チームの責任範囲を明確にしたい • 技術的負債の拡散を防ぎたい • 変更影響を局所化したい • コードベースを理解しやすくしたい • 業務の成長に耐えたい などの は必ず守りたい。 • モデルの混在を避けたい • テスト範囲を絞りたい • 依存関係を制御したい • 将来の分割・置き換えに備えたい サービス境界 モジュラーモノリス マイクロサービス • デプロイ単位が単純 • ローカル開発が軽い • プロセス間通信を最適化したい • デバッグしやすい • 分散システムの複雑さを避けた • 初期開発速度を出しやすい アーキテクチャの思想上、 • 境界をコード上で育てられる い が良くなる仕組みは 取り入れる必要はない。 • 運用監視の構成がシンプル • サービスごとにスケールできる • チームごとの自律性を高めやす • サービスごとに独立してデプロイ い できる • 技術選定の自由度が上がる 開発者体験と引き換えに マイクロサービスの特性は • 障害の影響範囲を限定しやす マイクロサービスのメリット い 当然享受する。 一部は受けられない。 開発者体験 積極的に取り入れたい。 モジュラーモノリス特有で 採用が難しい 2026/05/30 マイクロサービスでも 享受したいメリット 開発者体験として トレードオフ 特に大切にしたい Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring 部分的に 放棄できそうなメリット © 2026 Simplex Inc. 20

DBの扱い 1 2 3 DBはすでに、用途や環境に応じて実行形態を切り替えている。 ローカル環境 検証環境 本番環境 開発者ごとにDBコンテナを立て、手元 で素早く確認する。 必要に応じて共用DBを利用する。 複数サービスが接続する共有DB、ま たは検証用DBを用意し、結合確認・ 受入確認に使う。 サービスごとにDBを分離し、所有する サービスだけが直接更新する。他サー ビスはAPI/Event経由で連携する。 ☞ 業務境界が適切に分離されていれば、実行形態が異なっていても管理できる。 2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 21

アプリケーションへの適用 1 2 3 業務境界は変えず、ローカルと本番で実行形態だけを切り替える。 下位(ローカル)環境 上位(本番)環境 業務領域(境界) は環境によって変化しない Context A Context B Platform (= Process) 気軽に 切り替えたい Context A Context B Platform (=Process) Platform (=Process) 実行形態だけ異なる。 1つのJVMでまとめて起動し、IDEで横断 デバッグや起動・テストを軽くする。 2026/05/30 サービスごとに独立して起動し、ネットワー ク越しに連携する。デプロイ・スケールなど をシステム要件に従って適用。 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 22

アプリケーションへの適用 (DDDとの関連) 1 2 3 DDDの境界をコードに落とし込むために、Application / Context / Platform の責務を分ける。 Application Context Platform 2026/05/30 外部からの入力を受け、ユー スケースを呼び出す。また、イ ベント駆動時のEvent Handlerなども責務とする。 業務ルールとユースケースを 閉じ込める。また、DIのコンテ ナの管理を行う。 Controller (Adapter) HTTPリクエストを受け取り、 Portを実装し、DB・外部 Usecaseを呼び出す。 API・Messageへ接続する Usecase Port 業務手順を表現し、 DomainとPortを組み合 わせる。 外部依存をインターフェー スとしてContext内に閉じ 込める。 実行環境・通信・起動制御を 担う。 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring Domain (Entity, Value) 業務概念・ルール・不変 条件を表現する。 © 2026 Simplex Inc. 23

Kotlinでの適用 1 2 3 Kotlinの軽量な仕組みを使い、同じContext定義を本番用・ローカル用に合成する。(デモでの利用技術を紹介) Ktor Application ※ 名称及びロゴは各権利者に帰属します。 KtorはKotlinとCoroutineを前提にした軽量Webフレームワーク。Spring Bootのように多くを 自動化するより、Routing・Plugin・起動設定を明示的に組み立てやすい。今回の構成では、 各Contextへの入口として使い、実行形態の違いをApplication層の外側に閉じ込める。 Koin Context ※ 名称及びロゴは各権利者に帰属します。 KoinはKotlin DSLで依存関係を定義できる軽量DIコンテナ。Dagger/Hiltのようなコード生成 やアノテーション中心の設計より導入が軽く、ContextごとにModuleを分けやすい。今回の構 成では、サービス境界ごとの依存を明示し、本番・ローカルで差し替える接点として使う。 Coroutine Platform ※ 名称及びロゴは各権利者に帰属します。 CoroutineはKotlin標準の非同期・並行処理の仕組み。Threadを直接扱うより軽量で、 Reactive Streamsのようなチェーン記述より逐次コードとして読みやすい。今回の構成では、複 数サービスの起動・停止・ライフサイクル制御をPlatform層で扱うために使う。 2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 24

デモ (下記に注目) https://github.com/simplexinc/jjug-ccc-2026-spring-multicontext にて公開 パッケージ構成 1 2 3 プラットフォーム層の実装 Application Context Platform 実行形態の変更 2026/05/30 コンテキストの表現 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 25

• https://github.com/simplexinc/jjug-ccc-2026-spring-multicontext

その他 1 2 3 応用 ① 応用 ② 制約 ① プロセスを分けるほどではない小さなコ ンテキストでも、先に境界だけを分けて おける。 リソース使用率の低いサービスを、同 一プロセスにまとめて運用する選択肢 を持てる。 開発基盤が複数に分かれている巨大 プロジェクトでは、全体適用は難しい 場合がある。 Context (+Context…?) Platform Context Context Context Platform Platform Small Context Context Platform Platform (Low usage) Context Platform (Low usage) 2026/05/30 制約 ② Context Context 同一アーキテクチャ上で開発する前提 があるため、言語やフレームワークを自 由に混在させたい場合には向かない。 Platform Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 26

まとめ 設計と実装を分断しない 1 業務の言葉・モデル・コードをつなげ、ビジネス価値に直結する開発を目指す。 業務境界をサービス境界にする 2 マルチコンテキストなDDDにより、モデルを分け、変更影響と責務を局所化する。 境界は保ち、実行形態は変える 3 サービス境界を守りながら、開発者体験を軽くできる。 2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 27

Thank you for your attention! 全体アンケート セッションアンケート https://x.gd/e6vlY https://x.gd/SETKa ご参加ありがとうございました。フィードバックをお願いします。 2026/05/30 Modular Monolith Locally, Microservices in Production @ JJUG CCC 2026 Spring © 2026 Simplex Inc. 28

• https://x.gd/e6vlY
• https://x.gd/SETKa