「【挑戦者必見！】DDDで複雑なシステムをリアーキテクチャをした1年の体験談withミライトデザイン」に参加してきました
2024/11/06（水）に開催された「【挑戦者必見！】DDDで複雑なシステムをリアーキテクチャをした1年の体験談withミライトデザイン」に参加してきたので、その内容と学んだことを共有したいと思います。
おことわり
この内容は非公式なものであり、自分なりに整理したものです。
本記事には誤りが含まれる可能性があります。
間違っている部分などがあれば、コメントいただけると助かります。<(_ _)>
本イベントについて
前回のイベントでRDRA・ICONIX・DDDを使ってリアーキテクチャを進めているお話をしてから、一年経過して学んだこと・気づいたことを共有する会でした。
askenでは中長期的なサービスの成長を見据えて、アーキテクチャの見直しとシステムの再設計を行っています。 この再設計の一環として、PHPで構築された既存システムをKotlinを用いた新システムに置き換えるという大きな決断をしました。
前回の勉強会「asken withミライトデザインのDDDのはじめ方 DDD x RDRA x ICONIX」から1年間リアーキテクチャを進める中で起こったことやアーキテクチャの変化をお話します。
今後DDDを始めたいと思っている方、現在DDDにチャレンジしているものの改善策を探している方のヒントになれば幸いです。
前回イベントの感想も記事にしています。
本イベントはアーカイブ動画として配信されるとのことです。
※配信され次第、リンクもはります
発表メモ
リアーキテクチャ×DDD 1年間の取り組みと進化
【概要】
リアーキテクチャの背景
価値検証をしたいため、開発速度を上げたい
コードの品質を上げたい
影響範囲や使用の調査に時間がかかる
コードとサービスの構造があってない
仕様がまとまってない
リアーキテクチャで取り組んだこと
RDRAを使って、サービス構造整理
ICONIXプロセスで仕様整理
DDDでコーディング
取り組むで気づいたこと
データ構造の整理にコストを掛ける必要がある
データ構造は変えずにリアーキテクチャを進める方針
数十億も超えるレコードがDBにあったため
新しいバリエーションや把握していないデータ構造があり、手戻り工数が発生した
ソースコードからデータ構造が把握しづらかったことが要因
廃止される機能に対して、どのくらいコストを掛けるか検討する必要がある
RDRA、ICONIX、DDDで進めた機能がA/Bテストの結果、廃止になった
現状の案
トランザクションスクリプトで実装する
分析フェーズを簡略化し、実装速度の早い設計にする（今のところの着地点）
リアーキテクチャと同様に設計実装する
【所感】
データ構造の整理にコストを掛けるという点にとても共感しました。
実際に自分もシステム可視化でRDRAを活用している時に、データ構造のルールは抜けてしまうのでどこで埋めるか迷っていたので、RDRAと別のやり方で整理すべきだなと思いました。
レガシーシステムにどう立ち向かうか 複雑さと理想と現実
【概要】
リアーキテクチャでどんな問題を解消しないといけないのか
さまざまな複雑
仕様の複雑
値のルール以外にも、サービスにおける扱い、不備、不正や算出式すべてが仕様
値のルール、使われ方、例外、ライフサイクル、関係する操作をはっきりさせるする必要がある
言葉の複雑
言葉の曖昧さ
違うものに同じ言葉を使わない、言葉の関係も整理する
コードの複雑
単一責任を満たさないコード
知識の分離ができていない
知らなくていいことをそのまま使える状態が良い
形だけで共通化せず、知識の共通化をする
分離の最小単位は仕様
データの複雑
ドメインモデルと違って、リファクタリングのしんどさが違う
不正の値はバリューオブジェクトなどで防ぐ
不正な値だけでなく、不正な組み合わせもバリデーションでカバーする
現実
仕様の複雑
値のルール以外は整理するしかない
コードを理解して言語化する
サービス構造はRDRAで結構わかる
単語の複雑
単語帳
概念モデリング
線をひける単語帳
仕様抽出することに集中する
同じ単語をみんなで使うのは難しい
隣人までを目標に
コードの複雑
知識の分離や集めた知識の再配置はむずかしい
IOが複雑に絡み合っている場合もむずかしい
データの複雑
昔のデータで不正もあるため、データパッチでなんとかするしかない
モデルとデータを分離するとクエリは大変になる
RWの最適化はしんどい
リアーキテクチャの活動割合
仕様整理：5割
実装：2割
テスト：3割
【所感】
今の業務でコードリーディングをする必要が出てきたので、とても勉強になりました。
やはり用語の定義だけでなく、用語の関係性も整理すべきだなと改めて感じました。
質疑応答
① RDRAの情報モデルではデータ構造の表現は難しい？
RDRAで定義する情報モデルは概念モデルの定義に近いため、データベース構造と異なることが多い
② リポジトリ層は冗長化しやすそうなので工夫してることは？
ドメインモデルをサービスに合わせている
そのため、技術的なカバーをしつつ、リポジトリ層の冗長はある程度許容している
③ 仕様整理フェーズの作業割合について
仕様整理、ドキュメンテーション、コーディングリーディングの割合は同じぐらい
④ 投資判断をする人にリアーキテクチャ作業を説得するコツは？
リアーキテクチャを実現なかった場合の影響（リスク）を語ることが大事
⑤ コーディング作業に入るのタイミングは？
決まったドキュメンテーションのレビューが通ってから、コーディング作業に入る
実際のコーディングで気づくことがあり、ドキュメンテーションに戻る
⑥ データベースで何か工夫していることは？
工夫はできてないので辛い
素朴な設計になっていることが課題となっている
⑦ テストの工夫
単体テスト、統合テストを実施している
結合テストはデプロイした後に行っている
⑧ インデックスやパフォーマンスチューニングはどうしてる？
DBのメトリクスを参考に実施している
⑨ RDRA書くときに使ってるツールは？
RDRAGraphツール（※1）を活用している
（※1）ツールについては以下の記事で書いている
⑩ 今後の展望
スケールや技術取得が難しいが、組織でリアーキテクチャが実施できるようにしていきたい
価値検証をどんどんしていきたい
全体の感想
実際の取り組んだお話は貴重なのでとても有意義な時間でした。
イベントの冒頭でお話していた通り、理想どおりには進まないんだなということを感じることができました。
自分も知見を共有できるように、本イベントのお話から学んだことを活かしたいと思いました。
YouTubeでやっているのは知らなかったので、過去のイベント動画も視聴しようと思います。