ryounasso blog
  1. Top
  2. アーキテクチャカンファレンス2025 参加ブログ - 境界とモジュラリティ編

アーキテクチャカンファレンス2025 参加ブログ - 境界とモジュラリティ編

2026/05/10
eventarchitecture

アーキテクチャカンファレンス 2025 に参加した。10 以上のセッションを聴いた中で、関連性のあるセッションごとにまとめていきたい。

目次

この記事で扱うセッション

ドメイン駆動設計とマイクロサービスアーキテクチャ

このセッションは、DDD の概念とマイクロサービスの関係を整理するパネルディスカッションだった。

ポイントとなる概念

概念 性質 空間
サブドメイン 業務を分析して分割したもの 問題空間
境界付けられたコンテキスト ユビキタス言語が通用する範囲 解決空間
集約 一貫性を保証すべき最小の単位 解決空間
マイクロサービス 独立してデプロイ可能なサービス 実装/インフラ空間

印象に残った点

「地形がサブドメイン、そこに引く国境線が Bounded Context」という比喩

これが個人的にわかりやすい比喩だった。サブドメインは現実の業務構造であり、変えられない。一方 Bounded Context は自分たちが引く線。地形は所与で、国境はデザインの対象、という構図が一発で頭に入る比喩だった。

4 つの概念は 1 対 1 対応ではない

サブドメインと Bounded Context は理想は 1 対 1 だが、ずれる時はずれる。Bounded Context とマイクロサービスはむしろ 1 対 1 じゃないパターンの方が多い、という話。
なぜずれるのかを考えると、それぞれが別の判断軸で切られているからかなと思う。サブドメインは業務の構造、Bounded Context はユビキタス言語の範囲、マイクロサービスはデプロイ・スケール独立性。軸が違う以上、境界が一致しないのは自然。

「巨大な泥団子 vs 分散した泥団子」

マイクロサービスは複雑性を消すのではなく、複雑性の所在を変えるだけ、という話。サービス内部の複雑性が減っても、サービス間の依存・調整・データ整合性で複雑性が増えるなら、トータルでは何も解決していない。

モノリスファースト原則

Martin Fowler の主張として「成功しているマイクロサービスの事例のほぼ全てが、大きくなりすぎたモノリスの分割から始まっている」「最初からマイクロサービスとして作ったシステムの多くは深刻な問題に直面している」という引用があった。マイクロサービスは目的ではなく手段である。

逆コンウェイ戦略の権限問題

「組織を変えたけど権限がなかった」という体験談も印象に残った。技術的に正しい組織形に変えても、その組織に必要な意思決定権限がついてこなければアーキテクチャは機能しない。

自分の感想

DDD やマイクロサービスの概念の関係性を考えることができた。また、考える上で気をつけるべきポイントも理解することができてよかった。

DDD が導く戦略的トレードオフ

Khononov さんのセッション。結合とトレードオフの観点から状況に応じた判断をするという主旨の内容だった。

印象に残った点

結合度の 4 階層

結合を「相手について何を知っているか=知識量」で 4 段階に分類する整理がわかりやすかった。

結合の種類 何を共有しているか 結合の強さ
Intrusive Coupling(侵入型) 実装の詳細 最強
Functional Coupling(機能) 機能そのもの 強
Model Coupling(モデル) ビジネスモデル 中
Contract Coupling(契約) API/契約のみ 最弱

カプセル化が高い = 共有する情報が少ない = 結合が弱い、という関係性。

「結合が剥がれるには逆方向のエネルギーが必要」

放置すれば結合は強くなる方向に進む。意識的に逆方向の力を加え続けないと、知識は漏れていき、システムは密結合化していく。これは設計を運用する上で重要な観点だと思った。

modularity = strength XOR distance

セッションの中で提示された定式。距離(物理 + 組織)という変数を結合に組み合わせて、

  • 結合が強い ∧ 距離が近い → モジュラリティ OK
  • 結合が弱い ∧ 距離が遠い → モジュラリティ OK
  • 結合が強い ∧ 距離が遠い → 最悪(密結合なのに別チームが触る)

技術的に分けたつもりでも、組織的距離が遠いまま密結合を残すと、調整コストで詰まる。

揮発性(Volatility)による統合パターンの選択

サブドメインを Core(高揮発)/ Supporting(低揮発)/ Generic(低揮発)に分けて、それぞれに適した統合パターンが違うという話。

  • 揮発性が高いなら Open-host Service (自分のドメイン機能を、外部から使いやすい形で公開して変化を吸収する)
  • 揮発性が低いなら Partnership (密に連携してコストを下げる)
  • Separate Ways (統合せず、それぞれが独自に同じような機能を実装するパターン) は Core でやってはいけない

Separate Ways は割り切りだが、Core(差別化要因)で重複実装すると、ビジネスルールの不整合・改善スピードの低下・投資の分散が起きる。揮発性が高くて重要なものは一元化、揮発性が低くて重要でないものは重複を許容。

自分の感想

このセッションは「境界の良し悪しをどう測るか」の観点を知ることができた。modularity = strength XOR distance は今後アーキテクチャを判断する場面で繰り返し参照するメンタルモデルになりそう。

Qiita アーキテクチャの 15 年史：モノリス Rails から巨大化するサービスの技術負債をどう解消するか

Qiita のリファクタリングの歴史を振り返るセッションだった。

印象に残った点

失敗と成功の違いは設計手法ではなく導入方法だった

これまでに Service 層の導入とモジュラモノリスの導入を試している。どちらも設計手法として悪いものではない。しかし、Service 層は失敗し、モジュラモノリスは成功した。その違いは設計の良し悪しではなく導入の進め方にあった、という話だった。

Service 層の導入が失敗した理由

  • 投入する範囲を広げすぎて、冗長なケースでデメリットが目立った
  • ノウハウが溜まっていない状態で投入してしまった
  • 問題が顕在化していないタイミングで導入してしまった

モジュラモノリスの導入が成功した理由

  • ゴールや解決する問題を具体的に定めた
  • 試行リファクタリングを行った
  • 「迷うポイント」を、少人数のうちに発見できるように動いた

試行リファクタリング

これは『レガシーコード改善ガイド』に書かれている手法らしい。変更したコードをリポジトリにチェックインせず破棄することを前提に、さまざまなリファクタリングを行って変更対象のコードを理解する、というもの。導入前に手元で「思いつくモジュール分割」を一通り試して、ハマりどころを把握しておく。

普段「リファクタリングしたらコミットする」が当たり前になっているので、理解のためだけにリファクタリングするという用途は意識的に取り入れたい。

自分の感想

「設計が正しくても、導入を間違えると失敗する」という事実を、対比事例で見れたのがよかった。リファクタリングは設計の知識だけでは足りなくて、準備が同じくらい重要。

「迷うポイントを少人数のうちに発見できるように動いた」という動きも重要だと感じた。チームを巻き込む前に、難所を発見しておく。

コード分割から始める複雑さの解消に向けた kintone のアーキテクチャ改善

サイボウズの kintone のリアーキテクトについてのセッション。コード分割を進めていく中で、複雑さの真因を発見した、という構成だった。

印象に残った点

メンタルモデルという視点

「メンタルモデル:システムがどのような部分から構成され、どう関係し合っているかという捉え方」という定義が出てきた。コード分割は、単にファイルを分ける作業ではなく、メンタルモデルに沿った形でコードベースを再構築する。

複雑さの真因の発見

複数のアクターの処理が 1 つのクラスに混在していたことが複雑さの原因だった

これは単に分割した訳ではなく、メンタルモデルに沿った分割を行ったからこそ見えてきた点なのかなと感じた。

ユースケースレイヤーの導入

最終的にユースケースレイヤーを導入したことで、トップダウン的な機能開発が可能になった、という結果。

自分の感想

ただ単に現状の状態をベースに分割するのではなく、メンタルモデルが先にあってそのモデルに沿う形でコードベースを構築していくことが重要だと感じた。
そのため、メンタルモデルという言葉を自分の中で改めて意識したい。コードを書くとき、テストを書くとき、レビューするとき、自分はどんなメンタルモデルでシステムを捉えているかを問い直すと、設計の判断が変わってくる気がする。

LUUP のモジュラーベースアーキテクチャの設計思想

電動キックボード等のシェアサービスを運営する LUUP のセッション。事業領域が広く、独自ドメインを多く含む中で、モジュラリティをどう設計しているかという話だった。

印象に残った点

広い事業領域での保守性確保

LUUP は事業領域が広く独自ドメインを含む。重要かつ緊急度の高い施策が多く、保守性の優先度が上がりにくい、というのが課題だった。

解決策は 2 つ。

  • コンテキストマップとモジュール化により再利用性の向上とドメイン知識の共通理解
  • Agentic Coding 親和性もあり開発スピードを落とさずに移行

チームごとの開発方針のサイロ化

もう一つの課題は、チームごとに開発方針が異なり、ドメインが共通化されず開発手法のサイロ化が進む、というもの。これも開発方針の統一とコンテキスト境界分離で対応している。

自分の感想

このセッションで興味深かったのは、Agentic Coding との親和性を設計の判断軸に入れていたところ。これはこれまではなかった視点。AI に書かせやすい設計、AI が理解しやすいモジュール構造、というのが今後のアーキテクチャ判断の一要素になっていくのかもしれない。

また、「広い事業領域 × 独自ドメイン × 保守性の優先度が上がりにくい」という条件は、多くの会社で当てはまる状況。コンテキストマップとモジュール化が万能薬ではないにしても、有効なアプローチの一つだと感じた。

無秩序からの脱却

リアーキテクトをどう進めるかについてのセッション。リアーキテクトを成功させるためのプロセスや組織への向き合い方が印象に残った。

印象に残った点

「アーキテクチャは伝播する。成功も失敗も伝播する」

最初に書いたコードが、その後の機能追加のテンプレートになる。参考にする際に「これが正しいか」を判断しないまま、同じパターンが何度も複製されていくこともある。
だから最初の数例を丁寧に作ることが、アーキテクチャ全体の品質を決める。

実証実験 — 思いつく限りのパターンを網羅実装

リアーキテクトを進める前に、実証実験として先行実装をした。ポイントは難易度別にパターンを網羅すること。

  • 簡単なパターン
  • 中難易度のパターン
  • 高難易度のパターン

簡単なケースだけで設計を確かめるのではなく、難しいケースで破綻しないかを事前に検証することで、本格展開後の手戻りを防ぐ。

リアーキテクトを始める前の話し合い

リアーキの最初に話し合いを行う。話し合いで扱う内容は 3 つ。

  • アーキテクチャに沿う動機づけ
  • 変化への受け入れ度合いの確認
  • 視座の変更

「アーキテクトは一番コード書けないといけない」

これは当たり前のように感じて、ただ、聞いた時にハッとした。

自分の感想

「アーキテクチャは伝播する」というのが、思い当たる節があった。最初のコードが規範になる、というのは経験的に納得感がある。だからこそ最初を雑に作ると、その雑さが何年も残る。

逆に言うと、リアーキテクトの初期に少人数で丁寧に作り込む期間を確保することが、長期的なアーキテクチャ品質に直結する。

全体の感想

6 セッションを通して、いくつか自分の中で繋がった話がある。

「最初の数例を丁寧に作る」と「迷うポイントを少人数で発見する」は同じ思想

Qiita の試行リファクタリング、nrslib さんの実証実験では「本格導入の前に難所を発見しておく」というアプローチを取っていた。リアーキテクトを成功させる共通パターンとして意識するべきだと感じた。

境界には複数のレイヤーがあり、それぞれ別の判断軸で切られる

「ドメイン駆動設計とマイクロサービスアーキテクチャ」の概念の整理と「 DDD が導く戦略的トレードオフ」 の 3 変数(強さ・距離・揮発性)を組み合わせると、境界設計の解像度が上がった気がする。サブドメインを切るときの軸、Bounded Context を切るときの軸、マイクロサービスを切るときの軸、それぞれ意識して使い分ける。

技術判断は組織判断と切り離せない

「ドメイン駆動設計とマイクロサービスアーキテクチャ」の「逆コンウェイ戦略の権限問題」、「 DDD が導く戦略的トレードオフ」 の「距離は組織的距離も含む」、nrslib さんの「リアーキの前に話し合う」、に共通していた。組織の面も合わせて考慮する必要があることを覚えておきたい。

参考リンク

share this article with XShare this article on X
profile
ryounasso