巨大レガシーシステムの戦略評価とリファクタリングにおけるDDDの活用事例

こちらのイベントで発表した資料です。
『ドメイン駆動設計を導入するためにやったこと』
https://modeling-how-to-learn.connpass.com/event/229811/

1. 巨大レガシーシステムの戦略評価と リファクタリングにおける DDDの活用事例 2022/01/17(月) READYFOR株式会社 ミノ駆動
2. お品書き • 自己紹介 • READYFOR株式会社の事業概要 • DDD導入準備：僕の入社 • 導入理由＆取り組み１：開発費用対効果の向上 • 導入理由＆取り組み２：リファクタリング • 取り組み３：変更容易性勉強会
3. 自己紹介　ミノ駆動 READYFOR株式会社のバックエンドエンジニア。 リファクタリング専門で仕事してます。 その他アーキテクチャ設計、設計支援（アドバイスや評価）、プロセス改善など、品質向 上にかかる様々な業務を遂行しています。 10年間大手電機で組み込み系やってきて、3年前にWeb系に移籍。 依然Web系の知識不足でハンデを感じており、ギャップを埋めるべく日々邁進中。
4. Twitterに不定期でクソコード動画を投稿してます
5. クソコードを退治しに行くゲームも作りました 『バグハンター2 REBOOT』 https://game.nicovideo.jp/atsumaru/games/gm22047 無料。 PC、スマホでプ レイ可。
6. 設計技術書を出版します • クソコードアンチパターン駆動の設計技術書です。 • 以下を解説する技術書です。 ◦ 変更容易性を貶める悪しきコードが抱える課題 ◦ 気をつけていても、ついつい陥りがちなポイント ◦ 改善に導くための設計方法と考え方 • サンプルコードを膨大に用意しております。400ページover。 • 技術評論社様より今春全国出版予定。ご期待くださいませ。 • （※なお、前ページのゲームは本書の副教材的な位置づけです）
7. READYFOR株式会社の事業概要 クラウドファンディング事業。寄附、資金調達を募るサービスです。 サービス上で実行者が寄附を呼びかけ、支援者が寄附金を支援します。
8. 取り組み準備：僕の入社自体がDDD導入 弊社READYFORのEngineering Manager「ミノ駆動さんを招き入れること自体がDDD の導入」。 オブジェクト指向カンファレンス2020では、僕を捕まえることを目論んで、僕の設計思想 を意識した登壇発表資料まで作成したそうな。当日は僕も登壇発表していたが、タイミン グが合わず、物理的な僕が誰なのか分からなくて、このときは捕まえられなかったとのこ と。 のちにTwitterで相互フォローになった直後、即ナンパされて入社するに至る。
9. 導入理由１： コアドメインを見定め、開発費用対効果を高めるため 巨大なシステムは、システムが解決する事業領域がとても広い。 一方で開発費用は有限。システムの全てに開発コストをかけられない。 コストの集中的投資に値する、競争優位性を発揮できる事業領域がどこかを見定めな ければならない。 それに対し、どこが中心的な事業領域なのか、そこにどういうシステムを立てるべきなの か、ほとんど整理されていなかった。
10. 事業の中心的領域「コアドメイン」 競争優位性を発揮し、最も価値を付加すべき事業領域を「コアドメイン」と呼ぶ。DDDの いの一番に登場する、超重要概念。DDDの真の主人公（DDDで登場する設計パターン はコアドメインの価値向上のための手段のひとつに過ぎない）。 どこがコアドメインかを分析し、システム開発の費用対効果を高めるためにDDDを導入 した。 分析にはコンテキストマップを使った。
11. 凡例： 娯楽を楽しみたい 顧客を整理したい 買い物したい 問題領域と解決領域 サッカー 動画配信 サービス TVゲーム 紙 Excel 方眼紙 CRM システム コンビニ ECサイト 移動 販売車 問題領域 解決領域
12. モノリシックシステムは複数の問題領域にまたがりがち 配送 注文 在庫 モノリシックな ECサイト モデルの解釈が混乱し、変更容 易性が低下しやすい。
13. 事業領域が不明、どのシステムと関係するかも不明 ？？？領域 ？？？領域 ？？？領域 システムA システムB システムC 【課題】弊社の場合、どんな事業領域があるのか具体的に整理されておらず、不明瞭であった。 また、どの事業領域にどのシステムが対応するのかも分かっていなかった。 このような状態でコアドメインを見定めるのは困難。
14. 取り組んだこと ドメインエキスパートと思わしき複数の関係者にインタビューを実施。 • 解決したい課題 • 目的 • ルール、どんな世界観か • 登場概念と、概念に対する考え方 etc… これらが明瞭に異なる境界が、問題領域（事業領域）の境界となる。
15. 事業領域を明確化し、コアドメインを特定できた 事業領域C 事業領域E 事業領域A 事業領域B 事業領域D (コアドメイン) システムA システムB システムC 手作業 ここは事業領域ごとにシ ステムを分離しよう ここに集中投資しよう。変更容 易性も高めていこう。 手作業で非効率だ。コアにも関係す るし、この手作業をシステム化しよ う。
16. 苦戦したこと：莫大な情報量 コンテキストマップを作る上で、いろんな部署に話を聞きに行ったり、資料を読み漁った り…。 様々な情報を頭に叩き込んだ上で、問題領域と解決領域（システム）の関係を整理して いかなければならなかった。 脳にものすごい負荷がかかって、毎日爆発しそうだった。半泣きで仕事してた。 入社したて＆リモートワークだったので有識者が誰か分からず、Slack上で「有識者は誰 だああああああ！！！！！」と絶叫巡回していた時期もあった。 大量の情報整理には、もっと人的リソースが必要であることが分かった。
17. 導入理由２：巨大レガシーシステムの技術的負債解消 巨大なRailsアプリの技術的負債により変更容易性に課題。 ローンチしてから約10年モノのレガシーシステム。 1つのモデルが複数の意味を持ってしまってFatになっていた。 Rails-wayだけでロジックを整理するのは限界。 そこで、上手くリファクタリングしたり、そもそも負債を作り込まなない開発を進めるため に、DDDの設計思想を導入する流れへ。
18. エンジニア全体の納得感醸成が課題 Rails-wayから外れたアーキテクチャに変えていく方針。 僕一人がDDDベースでリファクタしても、エンジニア全体に意図が理解されていなけれ ば混乱を招く。 また、他のエンジニアさんがRails-wayだけに固執して実装を進められると、負債がなか なか減らなかったり、逆に負債を作り込まれてしまう懸念もある。 したがって全体で負債を低減していくためには、エンジニア全体にDDDの利点を周知 し、納得感を醸成する必要がある。
19. 【余談】DDDを覚えたての頃のぼく 今からX年前、ずっと以前の職場にて ぼく「DDDすごいんですよ！DDDやりましょうよ！」 上司「何がすごいのかね？どんな課題を解決するの？」 ぼく「……」 上司「説明できないものを採用しようというわけ？」 ぼく「……」 こういう失敗があって、DDDとはなんぞやを学び直すキッカケになった。
20. 課題が導入技術と合致していることが重要 あらゆる技術は、何らかの課題を解決するために編み出される。 課題と一致していなければ、導入する価値がない（例えばグラフィック性能を向上したい のにキーボードを買ってくる人がいるだろうか？）。 DDDの導入も同様に、現場の課題が何であって、DDDによりどう解決されるのかを結 びつけて説明する必要がある。 特にRailsはDDDとの親和性が低いので、どう乗り越えるかを説明する必要があった。
21. 説明したこと DDDとは、コアドメインの価値を高め、長期的に成長体質にする設計思想。 具体的には、ソフトウェアの機能性と変更容易性の向上を促進する。 課題 解決方法 DBとの密結合 RepositoryでDB知識、つまりActiveRecordを隔離 FatModel、概念の混乱 コンテキストやユビキタス言語、VOやAggregateでドメイ ン概念を整理 全部DDDでやるのか コアドメインや、負債が特に酷い箇所に絞ってDDDでや る。それ以外はRails-wayでも良い。
22. アーキテクチャ Domain ActiveRecord Controller View Infrastructure Usecase
23. 上手くいった／いってること 皆さん負債に困っていたので、割とすんなり受け入れられた。 「巨大モデルが複数の意味持ってしまって混乱してるから、意味の違う概念単位で分割 する考えに賛成」という反応が多かった。 新規にコードを書くとき、DDDベースで設計実装する人が少しずつ増え始めた。僕が適 宜助言しているのもあって、要点をおさえた設計ができている。 プロダクションコードの増加に対して、負債の絶対量はほぼ変動なし。今後低減に向か うことを期待。
24. というSlackスタンプが爆誕しました
25. 苦労してること：Rails-way とにかくRailsの仕組みが邪魔でしょうがない。 ActiveRecordを中心に便利機能が集約しているために、ActiveRecordから離れようと すると凄まじい引力で引き戻されそうになる。 本当はpureなRubyクラスだけでドメインオブジェクトを構成したいが、どうしてもRailsと 妥協しなければならない局面がある。 そうした中でもActiveRecordを上手くRepositoryに隠蔽してpureなドメインオブジェクト を設計できると、嬉しさのあまり小躍りしたくなる。
26. 苦労してること：Ruby 型のサポートがないので、依存関係を正確に追跡できない。リファクタリング効率がどう しても落ちる。 Rubyに比べたら静的型付け言語のリファクタリングなんてヌルゲーです（暴論） そんな中でもリファクタして整理していくと、自分がリファクタした箇所だけ追跡性が静的 型付け並みに向上する。
27. 導入取り組み：変更容易性勉強会 ハンズオン形式の社内勉強会。 増田さんの『現場で役立つシステム設計の原則』を参 考テキストとして使用。
28. 勉強会の流れ • 開始前までに所定のページを予め読んでおく。例えばFirst Class Collectionパター ンのページを読んでおく。 • コミュニケーションツールSpatialChatを使用（次ページで解説） • SpatialChat上でグループに分かれる。 • 実際の製品コードから、First Class Collectionとして設計できそうなコードを探す。 • スクラッチで、まっさらな状態からFirst Class Collectionとして設計実装し直してみ る。 • 各グループごとに成果発表して知見を共有、議論。
29. SpatialChat（スペチャ）を利用 同じ部屋で、画面共有が複数可能。 他のグループがどんな実装をしてるのか様子を見れる。お互い刺激になる。