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