2019 5/11 レガシーをぶっつぶせ。

1. 抽象的な教えを
試行錯誤しながら解釈した
DDD の実践レポート
ほげさん

2. 2012 04 新卒入社 ど素人
１年くらい多重度をフランス語だと思ってた（→タジュード）
社会人歴の半分くらいは php でフロントエンド
後半の半分くらいは DDD をやっている
ここ１年くらいはテックリードみたいなことも
ScalaMatsuri とか Haskell Day に行ったりします
自己紹介

3. 設計ぽいやつ
1. DDDをHaskellで考える 業務ロジックとシステムロジック
2. 副作用ってなんだ？ 〜楽に小さく単体テストをしよう〜
チーム開発ぽいやつ
3. アジャイル / スクラム / チーム開発の［不吉な匂い］まとめ
4. GitHubを中心とした開発プロセス
予想に反していいねもらえたやつ
5. Pythonのimportについてまとめる
よく Qiita に投稿してます

4. 1. https://qiita.com/suzuki-hoge/items/82229b903655ca4b5c9b
2. https://qiita.com/suzuki-hoge/items/bad43630ad1ad723ca4a
3. https://qiita.com/suzuki-hoge/items/16af349035a497e30063
4. https://qiita.com/suzuki-hoge/items/a6e3bdc2cc1cf4e98ea1
5. https://qiita.com/suzuki-hoge/items/f951d56290617df4279e
記事 URL

5. §1 導入
〜何を言ってるのかさっぱりわからん〜

6. ある日「レガシーシステムの大規模リニュー
アルのために DDD チームを立ち上げるんだ
けど、そこに入ってね」と言われる
お前は性格的に大丈夫だろとか言われて教育
は１日、お題を使った訓練は数日しかなかっ
た

7. 何やらレビュー時に抽象的なフレーズが飛び交ってい
る
「業務をドメインで表すんだ」
「それの振る舞いはなに？」
「ドメインではメモリ上の更新だけ」
「ドメインを育てろ」
domain-driven design quickly やエヴァンス本の内容
が口伝を重ね、現場ではこう言う様になったんだろう

8. しかし！
初学者がこんな指示でものづくり出来るはず
がない
DDD ってのが何を言いたいのか、みんなが僕
に何をさせたいのか、全くわからない

9. それでもコードを書いてみたんだけど、「君の
Domain 層からは業務を感じない」とかわけわ
かんないこと言われた
辛いので「何を満たせば DDD だって認めてく
れるか、さっさと具体的に教えてくれ」って思
ってた

10. なので、今日は似たような「DDD よくわから
ん」って人に、失敗しながらたどりついた僕
なりの具体的な解釈を紹介してみたいと思い
ます

11. §2 単語の抽出 - 名詞を探せ？
〜ドメインに何もない〜

12. 何から始めれば良いか全くわからん
やってみないことには進まないので、とりあ
えずみんながやってる名詞の抽出ってのをや
ってみよう
例題を用意して試してみます
アプローチ

13. メアドと年齢と住所とプランと
スマホ（任意）を選択して申し
込む
プランは 3GB(pv001) から
20GB(pv004) までを取り扱う
（pv001 は社内システムに登録する連携コードの
ようなもの）
未成年は申し込めない
本州以外は配送に+2日必要に
なる
名詞を探す
メアドと年齢と住所とプランと
スマホ（任意）を選択して申し
込む
プランは 3GB(pv001) から
20GB(pv004) までを取り扱う
（pv001 は社内システムに登録する連携コードの
ようなもの）
未成年は申し込めない
本州以外は配送に+2日必要に
なる
ピックアップ

14. 絵にする
メアドと年齢と住所とプランと
スマホ（任意）を選択して申し
込む
プランは 3GB(pv001) から
20GB(pv004) までを取り扱う
（pv001 は社内システムに登録する連携コードの
ようなもの）
未成年は申し込めない
本州以外は配送に+2日必要に
なる
描く

15. ただのデータの箱になった
箱同士に線が引けない
何をすると何が起こるのか、この絵ではさっぱりわ
からない
+2日って話はどこ行っちゃったの？
コードの大半は Application 層と Infrastructure 層に
書くことになった（後述）
結果

16. 「業務をドメインで表す」
→ ただのデータの箱になりましたけど…
「振る舞いを考える」
→ getter ならたくさんありますけど…
「ドメインではメモリ上の更新だけ」
→ ？？？
「ドメインを育てる」
→ ？？？
ここまでの理解と解釈

17. 全然良さそうなやり方に見えない
とりあえず Domain 層がスカスカなのが悪い
んだろう
大事なものが何か考えて、ドメインに移して
みよう
次のアプローチ

18. §3 ドメインに集める？
〜集めすぎた〜

19. 処理順とか条件分岐による DB 更新とか外部
システム連携が大事なもの（=ドメイン）だ
と思った
だって結合テストとかで細かく確認するのっ
てこの辺だもの
仮説

20. Application 層にあった条件分岐や DB 更新を移動
先ほどのドメインの周辺に存在した大量のコードを、
全部 申込ドメイン#申込()に移動した
変更

21. 絵から読み取れない情報が多い…
実は…

22. 線は数本あるけどあんまり情報が増えてない
リポジトリの引数が多くて雑多
Domain 層のテストコード書くのがものすご
く大変
DB のテストデータとかメーラのモックとか外部システム
のスタブとか全部揃えないといけない
結果

23. 「業務をドメインで表す」
→ 更新処理や通信処理が全部集まったけど、辛い…
「振る舞いを考える」
→ 巨大な 申込() が１つだけならありますけど…
「ドメインではメモリ上の更新だけ」
→ ？？？
「ドメインを育てる」
→ ？？？
ここまでの理解と解釈

24. 次のアプローチ
どうやら大事なもの（= ドメイン）は更新処理じゃあな
いみたいだ
申込() は変更処理をしているけど、変更結果を return で
もらえてないからテストがしづらいのではないか
そういう処理を直そう、目印は void だ、void をなくそう
return するものや処理名から見直した方が良さそうだ、
なら名詞じゃあなくて動詞を探した方が良さそう

25. §4 単語の抽出 - 動詞を探せ！
〜void の排除も〜

26. メアドと年齢と住所とプランと
スマホ（任意）を選択して申し
込む
プランは 3GB(pv001) から
20GB(pv004) までを取り扱う
（pv001 は社内システムに登録する連携コードの
ようなもの）
未成年は申し込めない
本州以外は配送に+2日必要に
なる
動詞を探す
メアドと年齢と住所とプランと
スマホ（任意）を選択して申し
込む
プランは 3GB(pv001) から
20GB(pv004) までを取り扱う
（pv001 は社内システムに登録する連携コードの
ようなもの）
未成年は申し込めない
本州以外は配送に+2日必要に
なる
ピックアップ

27. void を排除したいのでインパラ→「メソッド名」→アウトパラの形にする
メアドと年齢と住所とプランと
スマホ（任意）を選択して申し
込む
プランは 3GB(pv001) から
20GB(pv004) までを取り扱う
（pv001 は社内システムに登録する連携コードの
ようなもの）
未成年は申し込めない
本州以外は配送に+2日必要に
なる
メアドと年齢と住所とプ
ランとスマホ→「申し込
む」→？？？
未成年→「申し込めない
」→ ？？？
本州以外→「必要になる
」→ ？？？
まだ日本語で整理

28. まとめたり考えたり聞き出したりして、意地でも埋める
メアドと年齢と住所とプ
ランとスマホ→「申し込
む」→？？？
未成年→「申し込めない
」→ ？？？
本州以外→「必要になる
」→ ？？？
申込内容（メアドと年齢と住所とプ
ランとスマホ）→「申し込む」
→受付内容
未成年→「申し込めない」→
何らかのエラー
本州以外→「必要になる」→
配送予定日
受付内容→「送信する」→メ
ール
情報集め

29. やっと絵を考える
申込内容（メアドと年齢と住所とプ
ランとスマホ）→「申し込む」
→受付内容
未成年→「申し込めない」→
何らかのエラー
本州以外→「必要になる」→
配送予定日
受付内容→「送信する」→メ
ール
線があり、return している

30. 最初と比べて随分と違う絵になった（詳細は割愛）
void を辞めるには return するクラスが必要だ、そ
のクラスは文書にある単語とは限らないっぽい
メソッドの整理はインパラ、アウトパラの整理も必
要とするのでドメインクラス同士が関係し出す
すごいテストコード書きやすい！
しかもテスト実行早い！
結果

31. 「業務をドメインで表す」
→ ドメインクラスが何に依存して何を算出するか、その整
理のことっぽい
「振る舞いを考える」
→ ドメインクラスを算出するメソッド名のことっぽい
「ドメインではメモリ上の更新だけ」
→ Domain 層から処理順やデータアクセスを排除して上記
２つに集中しよう
「ドメインを育てる」
→ 文書には明記されていない単語がありそう
ここまでの理解と解釈

32. とは言え、void じゃあないもの全てがドメイ
ンなわけでもないだろう
ドメインか否かの境界があるはずだ
それに、広大な Domain 層を見ても隠れてい
る単語を見つけるなんて無理だろう
ドメインの中にも境界があるはずだ
次のアプローチ

33. §5 境界を決める
〜独立して育てる〜

34. 1. Domain 層から Application 層や
Infrastructure 層への依存を断つ
2. ドメインが知る他のドメインを減らす
3. ドメイン間に線を引く時は、変更頻度が低
い方に向けて線を引く
やったこと

35. 1. Domain 層が知っている外の都合があったので排除し
た
仕様は変わっていないのに
頻繁に修正するクラスがあるので気がついた
クラスを分ける
ドメインからエラーメッセージを
辿れなくなった

36. 2. 知りすぎているドメインを切断した
テストコードで用意する変数が
異様に多いので気が付いた
引数を変えて import 文を減らす
メールからプランを辿れなくなったし、
プランが増えてもメールには関係ない

37. 3. 変わりやすい方に依存している線を逆にした
配送業者の変更が多くて頻繁に supply を
修正していたので気がついた
依存性逆転の原則の適用
( dependency inversion principle )
supply → supplier の線が
supply ← supplier の線になった

38. 1. Domain 層から Application 層や Infrastructure 層への依存
を断つ
→ ドメイン外の都合に振り回されない
2. ドメインが知る他のドメインを減らす
→ ドメインがコンパクトになる
3. ドメイン間に線を引く時は、変更頻度が低い方に向けて
線を引く
→ 修正箇所が減る
結果

39. やることが明確でコンパクトなドメインにな
り、考察がやりやすい
依存が少ないので、安心して変更出来る
結論

40. 「業務をドメインで表す」
→ ドメインクラスが何に依存して何を算出するか、その整理の
ことっぽい
「振る舞いを考える」
→ ドメインを算出するメソッド名のことっぽい
「ドメインではメモリ上の更新だけ」
→ Domain 層から処理順やデータアクセスを排除して上記２つ
に集中しよう
「ドメインを育てる」
→ 文書には明記されていない単語がありそう、なので範囲を絞
っておくと考えやすいし変更しやすいってことだ
ここまでの理解と解釈

41. モデリング結果が ER 図になるってよくあると思うんだけ
ど、これも Domain 層 → Infrastructure 層の依存と本質は
同じだと思う
ドメインとテーブルは同じペースで育たないって考えると
理解するヒントになるかな、と思っている
例えばエディタでクラスの分割したあと、データ移行でテ
ーブルの分割もセットでしない
変更する頻度や理由が違うものは、分けておくと良さそう
理解（余談：モデルと ER 図）

42. §6 まとめ

43. 「業務をドメインで表す」
→ ドメインクラスが何に依存して何を算出するか
「振る舞いを考える」
→ その算出のこと
「ドメインではメモリ上の更新だけ」
→ Domain 層から処理順やデータアクセスを排除して上記
２つに集中しよう
「ドメインを育てる」
→ 文書には明記されていない単語がありそう、なので範囲
を絞っておくと考えやすいし変更しやすい
再掲

44. 今日は全く触れられなかったけど、ユビキタ
ス言語とか、他にも大事なことは沢山ある
そういう教えをちゃんと１つずつ噛み砕いて
実践できていることが、変化に対応できると
か高速に変更出来るって事に繋がるはず
くらいで捉えちゃって良いと思ってる

45. §7 今後やりたいこと
〜おまけ〜

46. エラー設計
別のパラダイムでの DDD
参照設計

47. 設計時点でレイヤー毎に起きるエ
ラーを限定する
だって起きる理由もその後の対処
も違うから
特にシステムのエラーとビジネス
のエラーは絶対に分けたい
できるだけ型情報にして図示する
コンパイルチェックに頼る
エラー設計はこんな感じでできないかと妄想中

48. 今の DDD の理解は
Haskell 経験からの思
いつきと独学でしかな
いので、ちゃんと学び
たい
ちょっとずつ読み進め
てる、新たな発見が待
ち遠しい
FP での DDD を試してみたい
https://www.amazon.co.jp/Domain-Modeling-Made-Functional-Domain-Driven-ebook/dp/B07B44BPFB

49. 巨大 SQL は保守できないし Domain 層にならない
かといって更新と同じドメインクラスを無策に流用
すると、性能が悪いとか、変なドメインになったり
する
参照は更新と別で設計してみる様にし始めた
ドメインクラスに参照ルールをどの程度どうやって
書くか、性能とのトレードオフはどう考えるのか
参照って更新とは別な難しさがある

50. まだまだ色々迷ってる、疑問も尽きない

51. けど、冒頭で疑問だった「何を満たせば DDD
か教えろ」はいつのまにかどうでも良くなっ
てた

52. 目的は「脱レガシー」なのだから