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
natacon
September 30, 2022
Programming
1
1.1k
DDDにどう立ち向かう?リファクタリングのあれこれ
2022/9/29 3社合同DDD勉強会
natacon
September 30, 2022
Tweet
Share
More Decks by natacon
See All by natacon
"個"の集まりに"チームというフィクション"をデザインしてみた ― 認知とつながりが変わると、アウトカムの捉え方も変わる ―
natacon
0
67
Backend LT フェーズ変化、プロダクトの成長に伴う技術的変遷
natacon
0
140
課題解決ではなく、価値創造を求めるVoicyの開発チームの組織設計と立ち上げの勘所
natacon
5
1.5k
契約による設計の「契約」とは何を指しているか
natacon
0
390
DDD導入にどう立ち向かう? 開発現場への適用方法あれこれ②
natacon
1
440
DDD導入にどう立ち向かう? 開発現場への適用方法あれこれ①
natacon
1
340
Other Decks in Programming
See All in Programming
0626 Findy Product Manager LT Night_高田スライド_speaker deck用
mana_takada
0
110
Goで作る、開発・CI環境
sin392
0
110
Result型で“失敗”を型にするPHPコードの書き方
kajitack
4
500
なぜ「共通化」を考え、失敗を繰り返すのか
rinchoku
1
570
たった 1 枚の PHP ファイルで実装する MCP サーバ / MCP Server with Vanilla PHP
okashoi
1
200
Create a website using Spatial Web
akkeylab
0
310
Blazing Fast UI Development with Compose Hot Reload (droidcon New York 2025)
zsmb
1
240
iOSアプリ開発で 関数型プログラミングを実現する The Composable Architectureの紹介
yimajo
2
220
Railsアプリケーションと パフォーマンスチューニング ー 秒間5万リクエストの モバイルオーダーシステムを支える事例 ー Rubyセミナー 大阪
falcon8823
4
990
Select API from Kotlin Coroutine
jmatsu
1
190
Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール? 〜
yodakeisuke
0
110
GoのGenericsによるslice操作との付き合い方
syumai
3
690
Featured
See All Featured
VelocityConf: Rendering Performance Case Studies
addyosmani
330
24k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
We Have a Design System, Now What?
morganepeng
53
7.7k
Agile that works and the tools we love
rasmusluckow
329
21k
Docker and Python
trallard
44
3.4k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
670
It's Worth the Effort
3n
185
28k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
124
52k
Practical Orchestrator
shlominoach
188
11k
Typedesign – Prime Four
hannesfritz
42
2.7k
Transcript
DDDにどう立ち向かう? リファクタリングのあれこれ 2022/09/29 株式会社Voicy 灘脇裕一 (@natacoon)
自己紹介 灘脇 裕一 Backend Engineer 機能開発チームリーダー スクラムマスター 2012.04 - HRTech
2020.07 - Voicy 本日はよろしくお願いします! @natacoon 好きなモノ: 服とねことスプラトゥーン 株式会社Voicy
本日のアジェンダ 影響範囲への意識を極力なくす 1 2 リファクタリングすべきはなにか
Voicy
Voicy 声で人の視界を広げ、ワクワクする社会へ。 たのしい声。せつない声。くやしい声。うれしい声。 ここに来れば、パーソナリティは本音を語ることができ、リス ナーは本音を聞くことができる。 そんな、声のプラットフォームを築くことで、人の視界は広が り、ワクワクする社会が生まれていく。2016年の創業以来、私 たちのこの想いは変わることはありません。
そのために、これからもVoicyは進化し続けます。
Voicy プロダクト
本日のアジェンダ 影響範囲への意識を極力なくす 1 2 リファクタリングすべきはなにか
前段 - もともとDDDは全くやっておらず、手続き的なコードが増えてきた - 以前はプロダクトに備えている機能はシンプルだったので、問題はなかった - が、徐々にプロダクト・開発組織も大きくなり始めたことにより、システムが実現しようと していることがコードから読み取りづらくなってきていた - 会社全体で概念レベルの理解がズレはじめていた
①のスライド ②のスライド
前段 今日の内容は Voicyで今後どうしていこうかを私が模索している 構想の途中経過を切り取って話してみる という回です
リファクタリングすべきはなにか
リファクタリングすべきはなにか ユーザーストーリーマッピング ユースケース ドメインモデル(概念レベル) モデリングはPdM、デザイナーとともにやってきている
リファクタリングすべきはなにか よーし、じゃあリファクタリングするぞ!
リファクタリングすべきはなにか どこから・・・?
リファクタリングすべきはなにか そもそもリファクタリングって? - マイクロリファクタリング - パターン指向リファクタリング - ドメインのリファクタリング(より深いモデルへのリファクタリング) エリック・エヴァンスのドメイン駆動設計 第3部
より深い洞察へ向かうリファクタリ ング より
リファクタリングすべきはなにか マイクロリファクタリング、パターン指向リファクタリングは技術的な観点から設計 の質を高める コードが何をしているかを理解しやすくする
リファクタリングすべきはなにか ドメインのリファクタリングは、ドメインに対する深い洞察をモデルに反映させる コードがなぜそれを行うのかをモデルに適用し、コードがなぜそうなっているのかを 明らかにする
リファクタリングすべきはなにか What → マイクロリファクタリング、パターン指向リファクタリング Why → ドメインのリファクタリング
リファクタリングすべきはなにか 事業としてプロダクトを成長させていくにあたって 本当に行いたいのはドメインのリファクタリング
リファクタリングすべきはなにか ドメインのリファクタリングにより モデルからさらなる洞察を行い、事業価値を高めるモデルを探求する活動を促進する これにより企業の活動を成長体質に変化させる
リファクタリングすべきはなにか とはいえ、ドメインのリファクタリングはたいていの場合において 一連のマイクロリファクタリングを伴う
リファクタリングすべきはなにか そのため、まずやるべきは マイクロリファクタリング、パターン指向リファクタリング
リファクタリングすべきはなにか どこから・・・?
リファクタリングすべきはなにか DDDを駆動している原則 - コアドメインに集中すること - ドメインの実装者とソフトウェアの実践者による創造的な共同作業を通じて、モ デルを探求すること - めいじてきな境界づけられたコンテキストの内部で、ユビキタス言語を語ること
リファクタリングすべきはなにか 極端にいえば、コアドメインさえモデルに準じた実装がされ、変更容易性を担保でき れば、事業価値を高める体質に変化させることはできる
リファクタリングすべきはなにか 書ききれなかったこと(ゴメンナサイ🙏) - コンテキストマップを作成してコアドメインを探す
影響範囲への意識を極力なくす
影響範囲への意識を極力なくす というか、まだそのモデルを適用できる状態ではないんだけど・・・
影響範囲への意識を極力なくす 大事な箇所だからこそ実装が込み入っていて手をつけるのが怖いし アーキテクチャにも課題があるんだけど・・・
影響範囲への意識を極力なくす 既存の実装を残しつつリファクタリングしてみない?
影響範囲への意識を極力なくす リファクタリングとは、コンピュータプログラミングにおいて、プログラムの外部か ら見た動作を変えずにソースコードの内部構造を整理することである。 Wikipedia より
影響範囲への意識を極力なくす つまり、既存コードすべてに手を加える必要はなく、既存を捨てつつ置き換えること もある(当たり前だけども) =捨て去るのはメソッド、クラス、はたまたユースケース実装ごとなど、置き換える 単位は様々 (マイクロサービスへの移行なども、大きな見方をすればリファクタリングの一部と 考えられる)
影響範囲への意識を極力なくす 例えば・・・ APIインターフェースを変えないけど、内部のアーキテクチャから見直したい
影響範囲への意識を極力なくす アプリケーションレイヤ以降を置き換えてみる
影響範囲への意識を極力なくす アプリケーション層のユースケース(サービス)ごと新規に実装し、プレゼンテー ション層からの呼び出しを切り替える (=既存コードを残したままにする)
影響範囲への意識を極力なくす いろんな粒度でのストラングラー(アプリケーション)を作っていく ビッグバンリライトを避けてリスクを軽減する マイクロサービスパターン Chapter13 1.2 モノリスを絞め殺す より
影響範囲への意識を極力なくす 「ビッグバンリライトが生み出すのはビッグバンだけ」 マーチン・ファウラー
影響範囲への意識を極力なくす デメリット - 捨てる予定のコードに新規機能が実装されてしまうとそのまま負債になる - いずれ再実装することになるので、開発にかける時間ももったいない
影響範囲への意識を極力なくす Kubernetes上に各種サービスが稼働してる おまけ: デプロイのはなし
影響範囲への意識を極力なくす カナリアリリースとして、1Podだけ既存のnamespaceのdeployment管理下にリファクタリング 後の呼び出しに変更した実装を適用したPodを配置する おまけ: デプロイのはなし リファクタ版
影響範囲への意識を極力なくす エラーが一定以上起こるようであればPodを取り除く おまけ: デプロイのはなし リファクタ版
まとめ - コアドメインを見つけて(定義して)集中しよう! - 一定以上大きいリファクタリングはストラングラーパターンを使って、既存 コードへの大きい変更を避けてみよう!
参考
お知らせ Meetyでカジュアル面談をやってます! 転職関係ない話もウェルカムなのでお話しましょう URL: https://meety.net/matches/KjRwJrKGDbKO Voicy ダウンロードリンク