Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

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

7.825 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Software
  • Hi there! I just wanted to share a list of sites that helped me a lot during my studies: .................................................................................................................................... www.EssayWrite.best - Write an essay .................................................................................................................................... www.LitReview.xyz - Summary of books .................................................................................................................................... www.Coursework.best - Online coursework .................................................................................................................................... www.Dissertations.me - proquest dissertations .................................................................................................................................... www.ReMovie.club - Movies reviews .................................................................................................................................... www.WebSlides.vip - Best powerpoint presentations .................................................................................................................................... www.WritePaper.info - Write a research paper .................................................................................................................................... www.EddyHelp.com - Homework help online .................................................................................................................................... www.MyResumeHelp.net - Professional resume writing service .................................................................................................................................. www.HelpWriting.net - Help with writing any papers ......................................................................................................................................... Save so as not to lose
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier

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

  1. 1. 抽象的な教えを 試行錯誤しながら解釈した DDD の実践レポート ほげさん
  2. 2. 2012 04 新卒入社 ど素人 1年くらい多重度をフランス語だと思ってた(→タジュード) 社会人歴の半分くらいは php でフロントエンド 後半の半分くらいは DDD をやっている ここ1年くらいはテックリードみたいなことも ScalaMatsuri とか Haskell Day に行ったりします 自己紹介
  3. 3. 設計ぽいやつ 1. DDDをHaskellで考える 業務ロジックとシステムロジック 2. 副作用ってなんだ? 〜楽に小さく単体テストをしよう〜 チーム開発ぽいやつ 3. アジャイル / スクラム / チーム開発の[不吉な匂い]まとめ 4. GitHubを中心とした開発プロセス 予想に反していいねもらえたやつ 5. Pythonのimportについてまとめる よく Qiita に投稿してます
  4. 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. 5. §1 導入 〜何を言ってるのかさっぱりわからん〜
  6. 6. ある日「レガシーシステムの大規模リニュー アルのために DDD チームを立ち上げるんだ けど、そこに入ってね」と言われる お前は性格的に大丈夫だろとか言われて教育 は1日、お題を使った訓練は数日しかなかっ た
  7. 7. 何やらレビュー時に抽象的なフレーズが飛び交ってい る 「業務をドメインで表すんだ」 「それの振る舞いはなに?」 「ドメインではメモリ上の更新だけ」 「ドメインを育てろ」 domain-driven design quickly やエヴァンス本の内容 が口伝を重ね、現場ではこう言う様になったんだろう
  8. 8. しかし! 初学者がこんな指示でものづくり出来るはず がない DDD ってのが何を言いたいのか、みんなが僕 に何をさせたいのか、全くわからない
  9. 9. それでもコードを書いてみたんだけど、「君の Domain 層からは業務を感じない」とかわけわ かんないこと言われた 辛いので「何を満たせば DDD だって認めてく れるか、さっさと具体的に教えてくれ」って思 ってた
  10. 10. なので、今日は似たような「DDD よくわから ん」って人に、失敗しながらたどりついた僕 なりの具体的な解釈を紹介してみたいと思い ます
  11. 11. §2 単語の抽出 - 名詞を探せ? 〜ドメインに何もない〜
  12. 12. 何から始めれば良いか全くわからん やってみないことには進まないので、とりあ えずみんながやってる名詞の抽出ってのをや ってみよう 例題を用意して試してみます アプローチ
  13. 13. メアドと年齢と住所とプランと スマホ(任意)を選択して申し 込む プランは 3GB(pv001) から 20GB(pv004) までを取り扱う (pv001 は社内システムに登録する連携コードの ようなもの) 未成年は申し込めない 本州以外は配送に+2日必要に なる 名詞を探す メアドと年齢と住所とプランと スマホ(任意)を選択して申し 込む プランは 3GB(pv001) から 20GB(pv004) までを取り扱う (pv001 は社内システムに登録する連携コードの ようなもの) 未成年は申し込めない 本州以外は配送に+2日必要に なる ピックアップ
  14. 14. 絵にする メアドと年齢と住所とプランと スマホ(任意)を選択して申し 込む プランは 3GB(pv001) から 20GB(pv004) までを取り扱う (pv001 は社内システムに登録する連携コードの ようなもの) 未成年は申し込めない 本州以外は配送に+2日必要に なる 描く
  15. 15. ただのデータの箱になった 箱同士に線が引けない 何をすると何が起こるのか、この絵ではさっぱりわ からない +2日って話はどこ行っちゃったの? コードの大半は Application 層と Infrastructure 層に 書くことになった(後述) 結果
  16. 16. 「業務をドメインで表す」 → ただのデータの箱になりましたけど… 「振る舞いを考える」 → getter ならたくさんありますけど… 「ドメインではメモリ上の更新だけ」 → ??? 「ドメインを育てる」 → ??? ここまでの理解と解釈
  17. 17. 全然良さそうなやり方に見えない とりあえず Domain 層がスカスカなのが悪い んだろう 大事なものが何か考えて、ドメインに移して みよう 次のアプローチ
  18. 18. §3 ドメインに集める? 〜集めすぎた〜
  19. 19. 処理順とか条件分岐による DB 更新とか外部 システム連携が大事なもの(=ドメイン)だ と思った だって結合テストとかで細かく確認するのっ てこの辺だもの 仮説
  20. 20. Application 層にあった条件分岐や DB 更新を移動 先ほどのドメインの周辺に存在した大量のコードを、 全部 申込ドメイン#申込()に移動した 変更
  21. 21. 絵から読み取れない情報が多い… 実は…
  22. 22. 線は数本あるけどあんまり情報が増えてない リポジトリの引数が多くて雑多 Domain 層のテストコード書くのがものすご く大変 DB のテストデータとかメーラのモックとか外部システム のスタブとか全部揃えないといけない 結果
  23. 23. 「業務をドメインで表す」 → 更新処理や通信処理が全部集まったけど、辛い… 「振る舞いを考える」 → 巨大な 申込() が1つだけならありますけど… 「ドメインではメモリ上の更新だけ」 → ??? 「ドメインを育てる」 → ??? ここまでの理解と解釈
  24. 24. 次のアプローチ どうやら大事なもの(= ドメイン)は更新処理じゃあな いみたいだ 申込() は変更処理をしているけど、変更結果を return で もらえてないからテストがしづらいのではないか そういう処理を直そう、目印は void だ、void をなくそう return するものや処理名から見直した方が良さそうだ、 なら名詞じゃあなくて動詞を探した方が良さそう
  25. 25. §4 単語の抽出 - 動詞を探せ! 〜void の排除も〜
  26. 26. メアドと年齢と住所とプランと スマホ(任意)を選択して申し 込む プランは 3GB(pv001) から 20GB(pv004) までを取り扱う (pv001 は社内システムに登録する連携コードの ようなもの) 未成年は申し込めない 本州以外は配送に+2日必要に なる 動詞を探す メアドと年齢と住所とプランと スマホ(任意)を選択して申し 込む プランは 3GB(pv001) から 20GB(pv004) までを取り扱う (pv001 は社内システムに登録する連携コードの ようなもの) 未成年は申し込めない 本州以外は配送に+2日必要に なる ピックアップ
  27. 27. void を排除したいのでインパラ→「メソッド名」→アウトパラの形にする メアドと年齢と住所とプランと スマホ(任意)を選択して申し 込む プランは 3GB(pv001) から 20GB(pv004) までを取り扱う (pv001 は社内システムに登録する連携コードの ようなもの) 未成年は申し込めない 本州以外は配送に+2日必要に なる メアドと年齢と住所とプ ランとスマホ→「申し込 む」→??? 未成年→「申し込めない 」→ ??? 本州以外→「必要になる 」→ ??? まだ日本語で整理
  28. 28. まとめたり考えたり聞き出したりして、意地でも埋める メアドと年齢と住所とプ ランとスマホ→「申し込 む」→??? 未成年→「申し込めない 」→ ??? 本州以外→「必要になる 」→ ??? 申込内容(メアドと年齢と住所とプ ランとスマホ)→「申し込む」 →受付内容 未成年→「申し込めない」→ 何らかのエラー 本州以外→「必要になる」→ 配送予定日 受付内容→「送信する」→メ ール 情報集め
  29. 29. やっと絵を考える 申込内容(メアドと年齢と住所とプ ランとスマホ)→「申し込む」 →受付内容 未成年→「申し込めない」→ 何らかのエラー 本州以外→「必要になる」→ 配送予定日 受付内容→「送信する」→メ ール 線があり、return している
  30. 30. 最初と比べて随分と違う絵になった(詳細は割愛) void を辞めるには return するクラスが必要だ、そ のクラスは文書にある単語とは限らないっぽい メソッドの整理はインパラ、アウトパラの整理も必 要とするのでドメインクラス同士が関係し出す すごいテストコード書きやすい! しかもテスト実行早い! 結果
  31. 31. 「業務をドメインで表す」 → ドメインクラスが何に依存して何を算出するか、その整 理のことっぽい 「振る舞いを考える」 → ドメインクラスを算出するメソッド名のことっぽい 「ドメインではメモリ上の更新だけ」 → Domain 層から処理順やデータアクセスを排除して上記 2つに集中しよう 「ドメインを育てる」 → 文書には明記されていない単語がありそう ここまでの理解と解釈
  32. 32. とは言え、void じゃあないもの全てがドメイ ンなわけでもないだろう ドメインか否かの境界があるはずだ それに、広大な Domain 層を見ても隠れてい る単語を見つけるなんて無理だろう ドメインの中にも境界があるはずだ 次のアプローチ
  33. 33. §5 境界を決める 〜独立して育てる〜
  34. 34. 1. Domain 層から Application 層や Infrastructure 層への依存を断つ 2. ドメインが知る他のドメインを減らす 3. ドメイン間に線を引く時は、変更頻度が低 い方に向けて線を引く やったこと
  35. 35. 1. Domain 層が知っている外の都合があったので排除し た 仕様は変わっていないのに 頻繁に修正するクラスがあるので気がついた クラスを分ける ドメインからエラーメッセージを 辿れなくなった
  36. 36. 2. 知りすぎているドメインを切断した テストコードで用意する変数が 異様に多いので気が付いた 引数を変えて import 文を減らす メールからプランを辿れなくなったし、 プランが増えてもメールには関係ない
  37. 37. 3. 変わりやすい方に依存している線を逆にした 配送業者の変更が多くて頻繁に supply を 修正していたので気がついた 依存性逆転の原則の適用 ( dependency inversion principle ) supply → supplier の線が supply ← supplier の線になった
  38. 38. 1. Domain 層から Application 層や Infrastructure 層への依存 を断つ → ドメイン外の都合に振り回されない 2. ドメインが知る他のドメインを減らす → ドメインがコンパクトになる 3. ドメイン間に線を引く時は、変更頻度が低い方に向けて 線を引く → 修正箇所が減る 結果
  39. 39. やることが明確でコンパクトなドメインにな り、考察がやりやすい 依存が少ないので、安心して変更出来る 結論
  40. 40. 「業務をドメインで表す」 → ドメインクラスが何に依存して何を算出するか、その整理の ことっぽい 「振る舞いを考える」 → ドメインを算出するメソッド名のことっぽい 「ドメインではメモリ上の更新だけ」 → Domain 層から処理順やデータアクセスを排除して上記2つ に集中しよう 「ドメインを育てる」 → 文書には明記されていない単語がありそう、なので範囲を絞 っておくと考えやすいし変更しやすいってことだ ここまでの理解と解釈
  41. 41. モデリング結果が ER 図になるってよくあると思うんだけ ど、これも Domain 層 → Infrastructure 層の依存と本質は 同じだと思う ドメインとテーブルは同じペースで育たないって考えると 理解するヒントになるかな、と思っている 例えばエディタでクラスの分割したあと、データ移行でテ ーブルの分割もセットでしない 変更する頻度や理由が違うものは、分けておくと良さそう 理解(余談:モデルと ER 図)
  42. 42. §6 まとめ
  43. 43. 「業務をドメインで表す」 → ドメインクラスが何に依存して何を算出するか 「振る舞いを考える」 → その算出のこと 「ドメインではメモリ上の更新だけ」 → Domain 層から処理順やデータアクセスを排除して上記 2つに集中しよう 「ドメインを育てる」 → 文書には明記されていない単語がありそう、なので範囲 を絞っておくと考えやすいし変更しやすい 再掲
  44. 44. 今日は全く触れられなかったけど、ユビキタ ス言語とか、他にも大事なことは沢山ある そういう教えをちゃんと1つずつ噛み砕いて 実践できていることが、変化に対応できると か高速に変更出来るって事に繋がるはず くらいで捉えちゃって良いと思ってる
  45. 45. §7 今後やりたいこと 〜おまけ〜
  46. 46. エラー設計 別のパラダイムでの DDD 参照設計
  47. 47. 設計時点でレイヤー毎に起きるエ ラーを限定する だって起きる理由もその後の対処 も違うから 特にシステムのエラーとビジネス のエラーは絶対に分けたい できるだけ型情報にして図示する コンパイルチェックに頼る エラー設計はこんな感じでできないかと妄想中
  48. 48. 今の DDD の理解は Haskell 経験からの思 いつきと独学でしかな いので、ちゃんと学び たい ちょっとずつ読み進め てる、新たな発見が待 ち遠しい FP での DDD を試してみたい https://www.amazon.co.jp/Domain-Modeling-Made-Functional-Domain-Driven-ebook/dp/B07B44BPFB
  49. 49. 巨大 SQL は保守できないし Domain 層にならない かといって更新と同じドメインクラスを無策に流用 すると、性能が悪いとか、変なドメインになったり する 参照は更新と別で設計してみる様にし始めた ドメインクラスに参照ルールをどの程度どうやって 書くか、性能とのトレードオフはどう考えるのか 参照って更新とは別な難しさがある
  50. 50. まだまだ色々迷ってる、疑問も尽きない
  51. 51. けど、冒頭で疑問だった「何を満たせば DDD か教えろ」はいつのまにかどうでも良くなっ てた
  52. 52. 目的は「脱レガシー」なのだから

×