「JJUG CCC 2025 Spring」に参加してきました

• 2025/6/7
• https://ccc2025spring.java-users.jp/
• https://jjug.doorkeeper.jp/events/183483

Feature Flag 開発を標準化し、加速させる Open Feature を導入する

SatohJohnさん(株式会社スリーシェイク)
https://speakerdeck.com/satohjohn/feature-flag-kai-fa-wobiao-zhun-hua-si-jia-su-saseru-openfeature-wodao-ru-suru

• Feature Flag
  • デプロイによるリリースではなく設定値の変更によってリリースする仕組み
  • デプロイしても即座に機能が反映されないようにしているのでデプロイ待ちを防げる
  • 緊急のロールバックもデプロイせずに設定値の変更でできる
• 種類
  • Release
    • トランクベース開発のため
    • メインブランチに積極的にマージできる
  • Ops
    • 運用面の制御のため
    • 負荷向上などの場合のサーキットブレーカー的な役割
  • Experimental
    • ABテストのため
  • Permission
    • 特定ユーザへ提供するため
• フラグの管理
  • 条件分岐が増えて読みにくくなる
  • フラグの組み合わせ問題
  • 不要になったフラグの削除
  • 設定の管理コスト
• OpenFeature
  • CNCFのFeature Flaggingの1つ
  • Feature Flagのための標準API
  • ロックイン回避のための標準化
  • 多くの環境でクライアントが提供されてる
    • Java/Go/Ruby/Rust/PHP/Python
    • Nest.js/React/Angular
  • Providerもたくさんある
  • https://openfeature.dev/ecosystem/

ビズリーチにおけるリアーキテクティングの実践事例 ～ 大規模システムを継続的に変革するための組織 × アーキテクチャ戦略～

Shintaro Kikuchiさん(Visionalグループ 株式会社ビズリーチ)

• レガシーコードの積み重ね
  • デリバリへの過渡なプレッシャー
  • 密結合な構造
  • 大規模プロジェクト
• プロダクトの改善
  • ポストモーテム文化
  • テストの自動化
  • QA
• アジリティ向上のためのリアーキテクト
  • マインド/プロセス/技術/組織
• リアーキ前
  • Javaの巨大モノリス
  • FEとBEが密結合
  • 利用者が異なる機能もまとまってる
  • 共有のデータベース
  • 手を入れた時の影響範囲の広さ
• アーキテクチャの改善
  • Bounded Contextでモジュール分割
    • 境界は非同期での連携
    • 同期な境界ができると密結合になってしまう
  • 将来的にはマイクロサービスもあるがまずは大きく切り出し
  • APIを切り出したらDBも分けようとしてる
  • 分割はまずは業務理解から
    • イベントストーミング
• 段階的な改善
  • ビジネス価値の高いものから
  • 使われてない機能の断捨離
  • 10%が使う機能を2倍にするより95%が使う機能を1.1倍に
• 変更容易性とテスト容易性
  • レイヤードアーキテクチャで関心事の分離
  • ドメインモデルでビジネスロジックの中核を表現
  • 集約とリポジトリパターンでデータアクセスを抽象化

実践Kafka Streams 〜イベント駆動型アーキテクチャを添えて〜

joker1007さん(Repro株式会社)
https://speakerdeck.com/joker1007/shi-jian-kafka-streams-ibentoqu-dong-xing-akitekutiyawotian-ete

• イベント駆動のアーキテクチャ
  • イベントバスとしてKafkaを採用
• Kafka Streams
  • JavaのCLIを書く感覚でストリームアプリケーションを作れる
  • Kafkaのトピックからconsumeして加工集計して別のトピックに流す
• パフォーマンス
  • レイテンシ
    • 1レコードをさばく時間とパーティション数で決まる
    • 1msecでも秒間1000しかさばけない
    • I/Oやネットワーク通信を減らす
    • 外部DBに依存させない
    • Redisとかでも1msecとかかかってしまう
  • パーティションのキー
    • 集約処理をするような場合パーティションキーを揃えておかないといけない
      • 後からは変えられない
  • データ量とパーティションサイズ

エンジニアリングでビジネスを加速する。モデル駆動開発という選択肢

Takahito Naganeoさん(シンプレクス株式会社)

• モデル駆動開発
  • ユースケースの洗い出し
    • 後から追加できるので厳密になりすぎなくていい
  • ユースケース内での状態変化の整理
  • モデルを作って振る舞いを実装していく
• モデルを使うと
  • 仕様と実装の乖離が起きない
  • 修正のスピード感があがる
• モデル駆動開発のコツ
  • モデル/ビジネスルールをまずは優先的に考える
  • 実装の詳細は後回しでいい
    • データがどこにあってどうやって取得するかとか
  • 依存性逆転の原則
    • 具体ではなく抽象に依存する
    • interfaceを作ってimplは後から
    • クリーンアーキテクチャに通ずる
  • ArchUnitでルール検知の自動化
    • パッケージ間の依存関係のテスト
  • 手続き的ではなく振る舞い的に
    • バリデーションやフィールドのセットなどをserviceｎ中に並べていくようなのはダメ
    • モデルに対する振る舞いとして実装する
    • モデルのpublicメソッドはビジネスロジックを隠蔽する
      • 高凝集になるように
    • フィールドは基本的にprivateで勝手な変更は許さない

これならできる！Kotlin・Spring・DDDを活用したAll in oneのマイクロサービス開発術

Tamio Ishiiさん(株式会社出前館)

• 4層をGradle Project化
  • domain model
    • Aggregate
      • EntityとValueObjectを最低1個ずつ持つ
    • Entity
    • ValueObject
  • usecase
  • application
    • OpenAPI generatorでクラスを自動生成してる
  • infra
  • バッチ
    • application runner
• テスト
  • 単体テスト(Kotest)
    • should spec
    • give when then
    • withData
  • 結合テスト(Testcontainers)
    • テスト用のDBやミドルウェアを構築できるように
    • CIでの並列実行
  • 性能テスト(Gatling)
    • Gradleプラグインで
    • 負荷をかけるライブラリ
• プロファイル
  • IntelliJのプロファイラ
  • どの処理がどれくらい呼ばれてどれくらい時間かかってるか

変化に強いテーブル設計の勘所

soudaiさん
https://speakerdeck.com/soudai/table-design-that-is-resistant-to-changes

• テーブル設計はAIがやってくれるようになるのか
  • まだならない
  • 労力は代替できるが能力は代替できない
  • 設計のサポートはしてくれるが設計は自分でやらないといけない
  • データベースはアプリよりも寿命が長い
• データベースは変化に弱い
  • commitしたデータは戻せない
  • カラムを追加したら過去のデータの対応が必要
  • 消していいかわからないデータ
  • 成長とともにデータは増える
  • ビジネス側に不要な制約を作ってしまう
• データベースには状態を持たせず事実だけを持たせる
• シンプルな設計
  • 事実だけを保存する
  • 重複がない
  • 不整合がない
  • nullがない
• 責務の大きさ
  • indexが4つ以上必要になったら深く考察が必要
• 情報と事実
  • 生年月日が事実で年齢はそのタイミングの情報
  • キャッシュのような情報はDBに持たないでロジックで算出する