- 2025/11/21
- https://architecture-con.findy-tools.io/2025
ドメイン駆動設計とマイクロサービスアーキテクチャ
しょぼちむさん(アマゾンウェブサービスジャパン合同会社)
福井 厚さん(アマゾンウェブサービスジャパン合同会社)
成瀬 允宣さん(株式会社コドモン)
https://speakerdeck.com/syobochim/ddd-x-microservice-architecture-findy-architecture-conf-2025
- マイクロサービス
- 1つのサービスの単位でデプロイできるように分けたもの
- 大きくなりすぎたものを分けていくというのが正攻法
- 最初からマイクロサービスするのはいいパターンではない
- サブドメイン
- 業務を分析し分割したもの
- 地形みたいな人の手が入らないもの
- 境界づけられたコンテキスト
- モデルを作るための境界
- 同じ意味の用語を適用できる範囲
- 市町村の線引きのように人の手が入るもの
- サブドメインと境界づけられたコンテキストの関係性
- 1対1？どちらかが大きい？
- 理想は1対1
- 言語は伝わるが現場の業務が分かれているパターン
- モデルの共有
- モノレポだとサービスの依存が見えて分かり易いが、CIなど共通のコードが膨らむのがつらい
- モノレポじゃないときにAIに他のプロジェクトがどこにあるか伝えるといい
- 1対1？どちらかが大きい？
- マイクロサービスどこから手をつけるか
- コアドメイン
- そこがうまくいかないと話にならないから
- 成果を早めに出したいから
- コアドメイン
- 効率的に作るには
SaaS拡大期の成長痛 〜モジュラーモノリスへのリアーキと生成AIの活用〜
今中 公紀さん(株式会社Finatext)
山崎 蓮馬さん(株式会社Finatext)
- 保険のシステム
- 商品が複雑
- 商品改定がある
- 会社によって微妙に違う商品がある
- 複雑なドメイン知識が必要
- アーキテクチャ
- CoreAPIで共通の保険ロジック
- 各テナントごとにBFF
- 数年の運用をして
- 似た構成のサービスの乱立
- 個社ごとにBFFを持ってる負荷
- プロジェクトごとの差異を見極める難しさ
- BFFにドメインロジックが流出
- マルチテナントとセキュリティ要件
- DBが完全にぶんりされているかとか
- 似た構成のサービスの乱立
- モジュラーモノリス
- モジュール感はPublicAPIで連携する
- Applicationは共有
- Usecase/Domain/Infraはそれぞれで
- UsecaseをたたくPublicAPIを置く
- DBは共有とモジュールごとどちらにするか
- 整合性が重要で高トラフィックではないから共有にした
- ただし基本は担当モジュールのPublicAPI経由でデータにアクセスする
- モジュール感はPublicAPIで連携する
- 同期呼び出し
- モジュール間の直接呼び出し
- Applicationレイヤー経由での複数モジュール順次呼び出し
- トランザクション
- リアーキテクチャでの生成AI活用
- TDD
- 明確な指示が必要
- ナレッジ共有
- コーディング規約
- CLOUDE.md
- タスク分解
- タスクを分けて段階的に作らせる
- 自分ならどういうステップでやるか考えてそれをプロンプトに
- TDD
セキュリティアーキテクトの設計思考──変化と制約を前提とした“再現性ある判断軸”とは
石川 朝久さん(東京海上ホールディングス株式会社)
- セキュリティアーキテクト
- セキュリティアーキテクチャ
- パターン
- Security Design Principles
- Security Architecture Pattern
- 予防 - 検知 - ハント
- 課題の洗い出し
- トレードオフ
- Bold-onからBuild-in
- 早期関与が非常に重要
- セキュリティもシフトレフト
- 手戻っての対応はコスト30倍というデータ
- 早期関与が非常に重要
- 早期相談できる文化
- 技術的施策
- 開発者が行うセキュリティを減らす
- 共通基盤を作ったり
- ソリューションの活用
- 開発者が行うセキュリティを減らす
- 組織プロセス的施策
- 開発者がやらないといけないことを仕組み化伴走支援
- レビューをいっしょにやる
- レビュー結果にセキュリティチームも責任を負う体制
- パイプラインにSASTなどを入れて認識できるように
- 人的施策
- 最終的な人の判断のための意識付け
- ビジネス要件に最大限に寄り添う
- 人質にはされないように
- 技術的施策
出前館アプリ進化論 〜アーキテクチャと組織のリアルな変革の舞台裏〜
植松 啓誠さん(株式会社出前館)
- 出前館
- 2000年サービス開始で25年の歴史
- 変革の契機
- 2020年にLINEと提携しサービス合併
- コロナ禍のタイミングも重なる
- 事業の成長を止めずに技術基盤を刷新する
- コロナ禍で400%の利用量
- 歴史があるシステムを止めずに対応
- 各コンポーネントの対応
- リアーキテクチャ
- 次の10年に向けて
- なぜこうなっているかをしっかり残す
- それがないのがつらかった
- 技術的負債との付き合い方
- ゼロ負債ではなくコントロールされた負債に
- なぜこうなっているかをしっかり残す
事業状況で変化する最適解。進化し続ける開発組織とアーキテクチャ
山田 圭一さん(キャディ株式会社)
https://speakerdeck.com/caddi_eng/shi-ye-zhuang-kuang-debian-hua-suruzui-shi-jie-jin-hua-sisok-kerukai-fa-zu-zhi-toakitekutiya
- 製造業で置きてる問題
- 個別最適化
- データのサイロ化
- 車輪の再発明
- CADDiでは
- 事業状況の変化
- 初期は加工品の受発注プラットフォーム
- 今は製造業のAIデータプラットフォーム
- プロダクトの変遷
不確実性に備える ABEMA の信頼性設計とオブザーバビリティ基盤
永岡 克利さん(株式会社AbemaTV)
山本 哲也さん(株式会社AbemaTV)
https://speakerdeck.com/nagapad/bu-que-shi-xing-nibei-eru-abema-noxin-lai-xing-she-ji-toobuzababiriteiji-pan
クラウドアーキテクチャ
- 発展性を考慮してハイブリッドクラウドで
- 配信システムはAWS
- メディアアセット管理
- ユーザシステムはGoogleCloud
- 行動ログ分析
- レコメンド牙案
- 一部システムはCloudflare
- 画像変換
- 仮想待機室
- 配信システムはAWS
- マルチリージョン
- 配信は信頼性重視で東京/大阪/ソウル
- 原則各リージョンに閉じたすステム
- ユーザシステムは東京/大阪/台湾
- 拡張性を重視して一部は台湾に
- 配信は信頼性重視で東京/大阪/ソウル
- 透過的な活用
オブザーバビリティ
- 統合監視基盤の課題
- システムが複雑
- 経験が浅いとどこで何が起こっているか判断できない
- 分散トレーシングの課題
- コストとのトレードオフ
- head based samplingしていてほしいとレースがとれないことも
- ランダムに選ばれるのでエラーのトレースが残らないことも
- Grafanaの活用を強化
- メトリクス/トレース/ログ/プロファイルをつなげるコストが高い
- 開発工数が必要
- これをやらないと辿ることができなくなり効率が落ちる
- 潜在的な未知の検証
- 製品はあっても有償でコストとの兼ね合い
- SaaS連携強化
- コスト課題
- インフラコストの7%をモニタリングとオブザーバビリティに投資すると合意
オブザーバビリティ基盤
- インフラ基盤の整備
- SDKの整備
- オブザーバビリティ基盤の構築
- コストを予算内におさめるにはサンプリングが必要
- head based sampling
- 確率で対象とするか判定
- 統計的な情報はとれる
- 必要な情報がとれないことも
- tail based sampling
- エラーやレイテンシーが高いなど条件をつけて対象とできる
- 設定するために開発が伴う
AIで加速する次世代のBill Oneアーキテクチャ ― 成長の先にある軌道修正
市川 達裕さん(Sansan株式会社)
https://speakerdeck.com/sansantech/20251121-2
- マイクロサービスの方針
- 業務ドメインで分割
- サービスごとのデータベース分割
- 非同期で連携
- 独自性と全体としての統一感のバランス
- AIエージェント時代への適応
- これまではアシスタント/今は自律的に行動
- Vibe CodingかっらAgentic Coding
- Vibe Codingでは中長期的な整合性や可変性が失われてしまう
- 人間が目的と制約を提示し動かす
- 開発プロセスのAI適用
- AI活用の4原則
- 常にAIを参加させる
- 人間参加型にする
- AIを人間のように扱う
- AIの進化を前提とする
- AI-Driven Development Lifecycle
- AIが実行し人間が監視
- AIがルーティンタスクを処理
- 人間は課題解決や価値創造
- マイクロサービスとの親和性
- コンテキストサイズが小さく保たれる
- チーム単位で管渠の整備ができる
- AI活用の4原則
- マイクロフロントエンド化
- AIの効果
