Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
巨大レガシーシステムの戦略評価とリファクタリングにおけるDDDの活用事例
Search
MinoDriven
January 18, 2022
Programming
8
10k
巨大レガシーシステムの戦略評価とリファクタリングにおけるDDDの活用事例
こちらのイベントで発表した資料です。
『ドメイン駆動設計を導入するためにやったこと』
https://modeling-how-to-learn.connpass.com/event/229811/
MinoDriven
January 18, 2022
Tweet
Share
More Decks by MinoDriven
See All by MinoDriven
技術的負債の怨霊と除霊方法 / ghosts-of-technical-debt
minodriven
10
3.6k
分岐を低減するinterface設計と発想の転換 / interface_design_idea.pdf
minodriven
15
5.4k
目的と抽象化の関係性から分かる、システムの設計精度を高める考え方 / purpose abstraction design
minodriven
21
7.7k
『良いコード/悪いコードで学ぶ設計入門』を一歩深める読み方 / deepen good code bad code
minodriven
17
6.2k
風刺動画「一枚岩モデル」で考える、DDDの境界付けられたコンテキスト / huge model vs bc
minodriven
19
36k
不幸を再生産しないための設計に対する向き合い方
minodriven
10
8.2k
「混ぜるな危険」を推進する設計
minodriven
8
3.6k
書籍『良いコード/悪いコードで学ぶ設計入門』でエンジニアリングの当たり前を変える
minodriven
6
4.8k
ビジネス考えてるかい?事業の持続的成長を促進させるシステム設計の考え方 / buisiness_purpose_system_design
minodriven
39
44k
Other Decks in Programming
See All in Programming
マイクロサービスがほしいと思ったときに本当に必要だったもの〜なぜ人は共通基盤の夢を見るのか〜 / why microservice
77web
4
810
ファイル先頭の use の意味、説明できますか? 〜PHP の namespace と autoloading の関係を正しく理解しよう〜 / namespace and autoloading in php
okashoi
2
400
Honoとhtmx
yusukebe
6
1.1k
PHP8の機能を使って堅牢にコードを書く
fendo181
6
2k
GitHub Copilot Tips and Tricks
yuichielectric
2
240
PHPerKaigi 2024〜10年以上動いているレガシーなバッチシステムを Kubernetes(Amazon EKS) に移行する取り組み〜
tshinowpub
1
170
Crafting a Own PHP - ウキウキ手作りミニマリストPHP
uzulla
4
960
品質が高いコードって何?Rev2.1
ickx
1
380
Learning Ruby
okuramasafumi
5
370
WasmOS: Wasmを実行する自作Microkernel
riru
0
360
phpunit/php-code-coverageって何をしてるんだ #phperkaigi
o0h
PRO
2
190
ADRを一年運用してみた/our_story_about_adr
hanhan1978
3
1.1k
Featured
See All Featured
Designing for Performance
lara
601
67k
jQuery: Nuts, Bolts and Bling
dougneiner
57
7.1k
Building Effective Engineering Teams - LeadDev
addyosmani
25
1.6k
Practical Orchestrator
shlominoach
180
9.6k
Building Applications with DynamoDB
mza
88
5.5k
Become a Pro
speakerdeck
PRO
8
4.2k
VelocityConf: Rendering Performance Case Studies
addyosmani
319
23k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
0
3.2k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
242
20k
10 Git Anti Patterns You Should be Aware of
lemiorhan
644
57k
The Power of CSS Pseudo Elements
geoffreycrofte
58
4.9k
The Invisible Customer
myddelton
114
12k
Transcript
巨大レガシーシステムの戦略評価と リファクタリングにおける DDDの活用事例 2022/01/17(月) READYFOR株式会社 ミノ駆動
お品書き • 自己紹介 • READYFOR株式会社の事業概要 • DDD導入準備:僕の入社 • 導入理由&取り組み1:開発費用対効果の向上 •
導入理由&取り組み2:リファクタリング • 取り組み3:変更容易性勉強会
自己紹介 ミノ駆動 READYFOR株式会社のバックエンドエンジニア。 リファクタリング専門で仕事してます。 その他アーキテクチャ設計、設計支援(アドバイスや評価)、プロセス改善など、品質向 上にかかる様々な業務を遂行しています。 10年間大手電機で組み込み系やってきて、3年前にWeb系に移籍。 依然Web系の知識不足でハンデを感じており、ギャップを埋めるべく日々邁進中。
Twitterに不定期でクソコード動画を投稿してます
クソコードを退治しに行くゲームも作りました 『バグハンター2 REBOOT』 https://game.nicovideo.jp/atsumaru/games/gm22047 無料。 PC、スマホでプ レイ可。
設計技術書を出版します • クソコードアンチパターン駆動の設計技術書です。 • 以下を解説する技術書です。 ◦ 変更容易性を貶める悪しきコードが抱える課題 ◦ 気をつけていても、ついつい陥りがちなポイント ◦
改善に導くための設計方法と考え方 • サンプルコードを膨大に用意しております。400ページover。 • 技術評論社様より今春全国出版予定。ご期待くださいませ。 • (※なお、前ページのゲームは本書の副教材的な位置づけです)
READYFOR株式会社の事業概要 クラウドファンディング事業。寄附、資金調達を募るサービスです。 サービス上で実行者が寄附を呼びかけ、支援者が寄附金を支援します。
取り組み準備:僕の入社自体がDDD導入 弊社READYFORのEngineering Manager「ミノ駆動さんを招き入れること自体がDDD の導入」。 オブジェクト指向カンファレンス2020では、僕を捕まえることを目論んで、僕の設計思想 を意識した登壇発表資料まで作成したそうな。当日は僕も登壇発表していたが、タイミン グが合わず、物理的な僕が誰なのか分からなくて、このときは捕まえられなかったとのこ と。 のちにTwitterで相互フォローになった直後、即ナンパされて入社するに至る。
導入理由1: コアドメインを見定め、開発費用対効果を高めるため 巨大なシステムは、システムが解決する事業領域がとても広い。 一方で開発費用は有限。システムの全てに開発コストをかけられない。 コストの集中的投資に値する、競争優位性を発揮できる事業領域がどこかを見定めな ければならない。 それに対し、どこが中心的な事業領域なのか、そこにどういうシステムを立てるべきなの か、ほとんど整理されていなかった。
事業の中心的領域「コアドメイン」 競争優位性を発揮し、最も価値を付加すべき事業領域を「コアドメイン」と呼ぶ。DDDの いの一番に登場する、超重要概念。DDDの真の主人公(DDDで登場する設計パターン はコアドメインの価値向上のための手段のひとつに過ぎない)。 どこがコアドメインかを分析し、システム開発の費用対効果を高めるためにDDDを導入 した。 分析にはコンテキストマップを使った。
凡例: 娯楽を楽しみたい 顧客を整理したい 買い物したい 問題領域と解決領域 サッカー 動画配信 サービス TVゲーム 紙
Excel 方眼紙 CRM システム コンビニ ECサイト 移動 販売車 問題領域 解決領域
モノリシックシステムは複数の問題領域にまたがりがち 配送 注文 在庫 モノリシックな ECサイト モデルの解釈が混乱し、変更容 易性が低下しやすい。
事業領域が不明、どのシステムと関係するかも不明 ???領域 ???領域 ???領域 システムA システムB システムC 【課題】弊社の場合、どんな事業領域があるのか具体的に整理されておらず、不明瞭であった。 また、どの事業領域にどのシステムが対応するのかも分かっていなかった。 このような状態でコアドメインを見定めるのは困難。
取り組んだこと ドメインエキスパートと思わしき複数の関係者にインタビューを実施。 • 解決したい課題 • 目的 • ルール、どんな世界観か • 登場概念と、概念に対する考え方
etc… これらが明瞭に異なる境界が、問題領域(事業領域)の境界となる。
事業領域を明確化し、コアドメインを特定できた 事業領域C 事業領域E 事業領域A 事業領域B 事業領域D (コアドメイン) システムA システムB システムC
手作業 ここは事業領域ごとにシ ステムを分離しよう ここに集中投資しよう。変更容 易性も高めていこう。 手作業で非効率だ。コアにも関係す るし、この手作業をシステム化しよ う。
苦戦したこと:莫大な情報量 コンテキストマップを作る上で、いろんな部署に話を聞きに行ったり、資料を読み漁った り…。 様々な情報を頭に叩き込んだ上で、問題領域と解決領域(システム)の関係を整理して いかなければならなかった。 脳にものすごい負荷がかかって、毎日爆発しそうだった。半泣きで仕事してた。 入社したて&リモートワークだったので有識者が誰か分からず、Slack上で「有識者は誰 だああああああ!!!!!」と絶叫巡回していた時期もあった。 大量の情報整理には、もっと人的リソースが必要であることが分かった。
導入理由2:巨大レガシーシステムの技術的負債解消 巨大なRailsアプリの技術的負債により変更容易性に課題。 ローンチしてから約10年モノのレガシーシステム。 1つのモデルが複数の意味を持ってしまってFatになっていた。 Rails-wayだけでロジックを整理するのは限界。 そこで、上手くリファクタリングしたり、そもそも負債を作り込まなない開発を進めるため に、DDDの設計思想を導入する流れへ。
エンジニア全体の納得感醸成が課題 Rails-wayから外れたアーキテクチャに変えていく方針。 僕一人がDDDベースでリファクタしても、エンジニア全体に意図が理解されていなけれ ば混乱を招く。 また、他のエンジニアさんがRails-wayだけに固執して実装を進められると、負債がなか なか減らなかったり、逆に負債を作り込まれてしまう懸念もある。 したがって全体で負債を低減していくためには、エンジニア全体にDDDの利点を周知 し、納得感を醸成する必要がある。
【余談】DDDを覚えたての頃のぼく 今からX年前、ずっと以前の職場にて ぼく「DDDすごいんですよ!DDDやりましょうよ!」 上司「何がすごいのかね?どんな課題を解決するの?」 ぼく「……」 上司「説明できないものを採用しようというわけ?」 ぼく「……」 こういう失敗があって、DDDとはなんぞやを学び直すキッカケになった。
課題が導入技術と合致していることが重要 あらゆる技術は、何らかの課題を解決するために編み出される。 課題と一致していなければ、導入する価値がない(例えばグラフィック性能を向上したい のにキーボードを買ってくる人がいるだろうか?)。 DDDの導入も同様に、現場の課題が何であって、DDDによりどう解決されるのかを結 びつけて説明する必要がある。 特にRailsはDDDとの親和性が低いので、どう乗り越えるかを説明する必要があった。
説明したこと DDDとは、コアドメインの価値を高め、長期的に成長体質にする設計思想。 具体的には、ソフトウェアの機能性と変更容易性の向上を促進する。 課題 解決方法 DBとの密結合 RepositoryでDB知識、つまりActiveRecordを隔離 FatModel、概念の混乱 コンテキストやユビキタス言語、VOやAggregateでドメイ ン概念を整理
全部DDDでやるのか コアドメインや、負債が特に酷い箇所に絞ってDDDでや る。それ以外はRails-wayでも良い。
アーキテクチャ Domain ActiveRecord Controller View Infrastructure Usecase
上手くいった/いってること 皆さん負債に困っていたので、割とすんなり受け入れられた。 「巨大モデルが複数の意味持ってしまって混乱してるから、意味の違う概念単位で分割 する考えに賛成」という反応が多かった。 新規にコードを書くとき、DDDベースで設計実装する人が少しずつ増え始めた。僕が適 宜助言しているのもあって、要点をおさえた設計ができている。 プロダクションコードの増加に対して、負債の絶対量はほぼ変動なし。今後低減に向か うことを期待。
というSlackスタンプが爆誕しました
苦労してること:Rails-way とにかくRailsの仕組みが邪魔でしょうがない。 ActiveRecordを中心に便利機能が集約しているために、ActiveRecordから離れようと すると凄まじい引力で引き戻されそうになる。 本当はpureなRubyクラスだけでドメインオブジェクトを構成したいが、どうしてもRailsと 妥協しなければならない局面がある。 そうした中でもActiveRecordを上手くRepositoryに隠蔽してpureなドメインオブジェクト を設計できると、嬉しさのあまり小躍りしたくなる。
苦労してること:Ruby 型のサポートがないので、依存関係を正確に追跡できない。リファクタリング効率がどう しても落ちる。 Rubyに比べたら静的型付け言語のリファクタリングなんてヌルゲーです(暴論) そんな中でもリファクタして整理していくと、自分がリファクタした箇所だけ追跡性が静的 型付け並みに向上する。
導入取り組み:変更容易性勉強会 ハンズオン形式の社内勉強会。 増田さんの『現場で役立つシステム設計の原則』を参 考テキストとして使用。
勉強会の流れ • 開始前までに所定のページを予め読んでおく。例えばFirst Class Collectionパター ンのページを読んでおく。 • コミュニケーションツールSpatialChatを使用(次ページで解説) • SpatialChat上でグループに分かれる。
• 実際の製品コードから、First Class Collectionとして設計できそうなコードを探す。 • スクラッチで、まっさらな状態からFirst Class Collectionとして設計実装し直してみ る。 • 各グループごとに成果発表して知見を共有、議論。
SpatialChat(スペチャ)を利用 同じ部屋で、画面共有が複数可能。 他のグループがどんな実装をしてるのか様子を見れる。お互い刺激になる。