Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
抽象的な教えを
試行錯誤しながら解釈した
DDD の実践レポート
ほげさん @大阪!
2012 04 新卒入社 ど素人
1年くらい多重度をフランス語だと思ってた(→タジュード)
社会人歴の半分くらいは php でフロントエンド、
後半の半分くらいは Java / DDD をやっている
ここ1年ちょっとはテックリードみたいなことも...
設計ぽいやつ
1. DDDをHaskellで考える 業務ロジックとシステムロジック
2. 副作用ってなんだ? 〜楽に小さく単体テストをしよう〜
チーム開発ぽいやつ
3. アジャイル / スクラム / チーム開発の[不吉な匂い]まとめ
4. Gi...
1. https://qiita.com/suzuki-hoge/items/82229b903655ca4b5c9b
2. https://qiita.com/suzuki-hoge/items/bad43630ad1ad723ca4a
3....
§1 導入
〜何を言ってるのかさっぱりわからん〜
ある日「レガシーシステムの大規模リニュー
アルのために DDD チームを立ち上げるんだ
けど、そこに入ってね」と言われる
お前は性格的に大丈夫だろとか言われて教育
は1日、訓練は数日しかなかった
DDD どころか Java もやったことないよ!?
何やらレビュー時に抽象的なフレーズが飛び交ってい
る
「業務をドメインで表すんだ」
「それの振る舞いはなに?」
「ドメインではメモリ上の更新だけ」
「ドメインを育てろ」
ほげさん「ヤベェとこ来ちゃったな」
domain-driven desig...
しかし!
初学者がこんな指示でものづくり出来るはず
がない
DDD ってのが何を言いたいのか、みんなが僕
に何をさせたいのか、全くわからない
フレーズが先行してた感じが強くて、抵抗が
すごかった …フレーズ駆動開発とでも言う?
それでもコードを書いてみたんだけど、「君の
Domain 層からは業務を感じない」とかわけわ
かんないこと言われた
辛いので「何を満たせば DDD だって認めてく
れるか、さっさと具体的に教えてくれ」って思
ってた
なので、今日は似たような「DDD よくわから
ん」って人に、失敗しながらたどりついた僕
なりの具体的な解釈をお話ししたいと思いま
す
§2 単語の抽出 - 名詞を探せ?
〜ドメインに何もない〜
何から始めれば良いか全くわからん
やってみないことには進まないので、とりあ
えずみんながやってる名詞の抽出ってのをや
ってみよう
例題を用意して試してみます
アプローチ
メアドと年齢と住所とプランとス
マホ(任意)を選択して申し込む
プランは 3GB(pv001) から
20GB(pv004) までを取り扱う
(pv001 は弊社の基盤システムが要求する連携コー
ドで、企画書にもコード値が頻出する)
未成年は申...
絵にする
メアドと年齢と住所とプランとス
マホ(任意)を選択して申し込む
プランは 3GB(pv001) から
20GB(pv004) までを取り扱う
(pv001 は弊社の基盤システムが要求する連携コー
ドで、企画書にもコード値が頻出する)
...
ただのデータの箱になった
箱同士に線が引けない
何をすると何が起こるのか、この絵ではさっぱりわから
ない
+2日って話はどこ行っちゃったの?
コードの大半は Application 層と Infrastructure 層に書く
ことになった(後...
「業務をドメインで表す」
→ ただのデータの箱になりましたけど…
「振る舞いを考える」
→ getter ならたくさんありますけど…
「ドメインではメモリ上の更新だけ」
→???
「ドメインを育てる」
→ ???
ここまでの理解と解釈
全然良さそうなやり方に見えない
とりあえず Domain 層がスカスカなのが悪い
んだろう
大事なものが何か考えて、ドメインに移して
みよう
次のアプローチ
§3 ドメインに集める?
〜集めすぎた〜
処理順とか条件分岐による DB 更新とか外部
システム連携が大事なもの(=ドメイン)だ
と思った
だって結合テストとかで細かく確認するのっ
てこの辺だもの
仮説
Application 層にあった条件分岐や DB 更新を移動
先ほどのドメインの周辺に存在した大量のコードを、
全部 申込ドメイン#申込()に移動した
変更
絵から読み取れない情報が多い…
実は…
線は数本あるけどあんまり情報が増えてない
リポジトリの引数が多くて雑多
テストコードのコンパイルを通すのがまず辛い
Domain 層のテストコード書くのがものすごく大変
DB のテストデータとかメーラのモックサーバとか外部システ
ムのスタブとか...
「業務をドメインで表す」
→ 処理順とか永続化処理が全部集まったけど、辛い…
「振る舞いを考える」
→ 巨大な void 申込() が1つだけならありますけど…
「ドメインではメモリ上の更新だけ」
→ ???
「ドメインを育てる」
→ ???
...
次のアプローチ
どうやら大事なもの(= ドメイン)は処理順や更新処理じ
ゃあないみたいだ
void 申込() は変更処理をしているけど、変更結果を return
でもらえてないからテストがしづらいのではないか
そういう処理を直そう、目印は vo...
§4 単語の抽出 - 動詞を探せ!
〜void の排除も〜
メアドと年齢と住所とプランとス
マホ(任意)を選択して申し込む
プランは 3GB(pv001) から
20GB(pv004) までを取り扱う
(pv001 は弊社の基盤システムが要求する連携コー
ドで、企画書にもコード値が頻出する)
未成年は申...
void を排除したいのでインパラ→「メソッド名」→アウトパラの形にする
メアドと年齢と住所とプランとス
マホ(任意)を選択して申し込む
プランは 3GB(pv001) から
20GB(pv004) までを取り扱う
(pv001 は弊社の基盤シ...
まとめたり考えたり聞き出したりして、意地でも埋め
る
メアドと年齢と住所とプ
ランとスマホ→「申し込
む」→???
未成年→「申し込めない
」→ ???
本州以外→「必要になる
」→ ???
申込内容(メアドと年齢と住所とプラン
とスマホ)→「...
やっと絵を考える
申込内容(メアドと年齢と住所とプラン
とスマホ)→「申し込む」→受付
内容
未成年→「申し込めない」→ 何
らかのエラー
本州以外→「必要になる」→ 配
送予定日
受付内容→「送信する」→メー
ル
線があり、return して...
最初と比べて随分と違う絵になった(詳細は割愛)
void を辞めるには return するクラスが必要だ、その
クラスは最初の文書にある単語とは限らないっぽい
メソッドの整理はインパラ、アウトパラの整理も必要
とするのでドメインクラス同士が関係...
「業務をドメインで表す」
→ ドメインクラスが何に依存して何を算出するか、その整理のこと
、っぽい
「振る舞いを考える」
→ ドメインクラスを算出するメソッド名のこと、っぽい
「ドメインではメモリ上の更新だけ」
→ Domain 層から処理順や...
とは言え、void じゃあないもの全てがドメイン
なわけでもないだろう
ドメインか否かの境界線があるはずだ
それに、膨大な企画書や広大な Domain 層を見
ても隠れている単語を見つけるなんて無理だろ
う
ドメインの中にも境界線があるはずだ
...
§5 境界を決める
〜独立して育てる〜
1. Domain 層から Application 層や
Infrastructure 層への依存を断つ
2. ドメインが知る他のドメインを減らす
3. ドメイン間に線を引く時は、変更頻度が低
い方に向けて線を引く
やったこと
1. Domain 層が知っている外の都合があったので排除し
た
仕様は変わっていないのに
頻繁に修正するクラスがあるので気がついた
クラスを分ける
ドメインからエラーメッセージを
辿れなくなった
2. 知りすぎているドメインを切断した
テストコードで用意する変数が
異様に多いので気が付いた
引数を変えて import 文を減らす
メールからプランを辿れなくなったし、
プランが増えてもメールには関係ない
3. 変わりやすい方に依存している線を逆にした
配送業者の変更が多くて頻繁に supply を
修正していたので気がついた
依存性逆転の原則の適用
( dependency inversion principle )
supply → supp...
1. Domain 層から Application 層や Infrastructure 層への依存を断つ
→ ドメインが、ドメインではない都合に振り回されない
(ドメインか否かの境界線)
2. ドメインが知る他のドメインを減らす
→ ドメインが...
やることが明確でコンパクトなドメインにな
り、考察がやりやすい
依存が少ないので、安心して変更出来る
結論
「業務をドメインで表す」
→ ドメインクラスが何に依存して何を算出するか、その整理のこと、っぽい
「振る舞いを考える」
→ ドメインクラスを算出するメソッド名のこと、っぽい
「ドメインではメモリ上の更新だけ」
→ Domain 層から処理順やデ...
モデリングすると ER 図ができるになるってよくあると思
うんだけど、これも Domain 層 → Infrastructure 層の依存
と本質は同じだと思う
ドメインとテーブルは同じペースで育たないって考えると
理解するヒントになるかな、と...
§6 まとめ
再掲
「業務をドメインで表す」
→ ドメインクラスが何に依存して何を算出するか、その整理のこと
「振る舞いを考える」
→ ドメインクラスを算出するメソッド名のこと
「ドメインではメモリ上の更新だけ」
→ Domain 層から処理順やデータアクセ...
今日は全く触れられなかったけど、ユビキタ
ス言語とか、他にも大事なことは沢山ある
そういう教えをちゃんと1つずつ噛み砕いて
実践できていることが、変化に対応できると
か高速に変更出来るって事に繋がるはず
くらいで捉えちゃって良いと思ってる
〜おまけ〜
§7 東京のあと考えたこ
と
東京開催の時のパネルディスカッションで「
テストコード要らないんじゃね(概訳)」って
話があった
(超乱暴にまとめると)手続き実装や型なし言
語だとテストたくさん必要だけど、型があれば
テストは減らせる / 要らない
そう言う面もあるのは賛成
けどいろんな人が参加してる中で前提を揃え
ないで言うのは勘違いを誘発すると思う
悶々と考えてたけど、やっぱり僕は 「
書くべき派」なので、今更だけど正面からア
ンチテーゼをぶつけたい
ちょっと待って
コンパイルしたって抜けないバグは山ほどある / ドメ
インクラスがあれば無条件で型の恩恵が得られるわけ
ではない
本気で実行時例外をなくす様に考えて作ってる?
テストコードが最初のそのドメインの利用者なので、
違和感や使い辛さとかに気付くチャン...
別にカバレッジ 100% しか認めないって言ってるわ
けではない
戦略的に減らそう、材料はたくさんあるはず
もう少し詳しく書いてみた -> 型がある言語で DDD
してたらテストはいらないの?
https://qiita.com/suzuki-...
§7 今後やりたいこと
〜おまけ2〜
設計時点でレイヤー毎に起きるエラーを限
定する
だって起きる理由もその後の対処も違うか
ら
特にシステムのエラーとビジネスのエラー
は絶対に分けたい
できるだけ型情報にして図示する、極力例
外を使わない、コンパイルの恩恵を大きく
する
本気で実...
今回は割愛しましたが、他にも色々迷ってる
、疑問も尽きない
けど、冒頭で疑問だった「何を満たせば DDD
か教えろ」はいつのまにかどうでも良くなっ
てた
目的は「脱レガシー」なのだから
Upcoming SlideShare
Loading in …5
×

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

1,108 views

Published on

Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD! コラボカンファレンス

Published in: Software
  • Be the first to comment

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

  1. 1. 抽象的な教えを 試行錯誤しながら解釈した DDD の実践レポート ほげさん @大阪!
  2. 2. 2012 04 新卒入社 ど素人 1年くらい多重度をフランス語だと思ってた(→タジュード) 社会人歴の半分くらいは php でフロントエンド、 後半の半分くらいは Java / 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 宣伝しますw
  5. 5. §1 導入 〜何を言ってるのかさっぱりわからん〜
  6. 6. ある日「レガシーシステムの大規模リニュー アルのために DDD チームを立ち上げるんだ けど、そこに入ってね」と言われる お前は性格的に大丈夫だろとか言われて教育 は1日、訓練は数日しかなかった DDD どころか Java もやったことないよ!?
  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. 「業務をドメインで表す」 → 処理順とか永続化処理が全部集まったけど、辛い… 「振る舞いを考える」 → 巨大な void 申込() が1つだけならありますけど… 「ドメインではメモリ上の更新だけ」 → ??? 「ドメインを育てる」 → ??? ここまでの理解と解釈
  24. 24. 次のアプローチ どうやら大事なもの(= ドメイン)は処理順や更新処理じ ゃあないみたいだ void 申込() は変更処理をしているけど、変更結果を 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. 東京開催の時のパネルディスカッションで「 テストコード要らないんじゃね(概訳)」って 話があった (超乱暴にまとめると)手続き実装や型なし言 語だとテストたくさん必要だけど、型があれば テストは減らせる / 要らない
  47. 47. そう言う面もあるのは賛成 けどいろんな人が参加してる中で前提を揃え ないで言うのは勘違いを誘発すると思う 悶々と考えてたけど、やっぱり僕は 「 書くべき派」なので、今更だけど正面からア ンチテーゼをぶつけたい ちょっと待って
  48. 48. コンパイルしたって抜けないバグは山ほどある / ドメ インクラスがあれば無条件で型の恩恵が得られるわけ ではない 本気で実行時例外をなくす様に考えて作ってる? テストコードが最初のそのドメインの利用者なので、 違和感や使い辛さとかに気付くチャンス 引数多くて辛いなぁとかモックサーバがないと動かないとか、そうい う味見を放棄している まさに学ぶ瞬間なのにもったいないよ! リファクタリングの促進のためにも、あってほしい 理由
  49. 49. 別にカバレッジ 100% しか認めないって言ってるわ けではない 戦略的に減らそう、材料はたくさんあるはず もう少し詳しく書いてみた -> 型がある言語で DDD してたらテストはいらないの? https://qiita.com/suzuki- hoge/items/127836df5ba57a13c94e
  50. 50. §7 今後やりたいこと 〜おまけ2〜
  51. 51. 設計時点でレイヤー毎に起きるエラーを限 定する だって起きる理由もその後の対処も違うか ら 特にシステムのエラーとビジネスのエラー は絶対に分けたい できるだけ型情報にして図示する、極力例 外を使わない、コンパイルの恩恵を大きく する 本気で実行時例外をなくす フィードバックサイクルを早くするために 、当然テストも書く エラー設計をこんな感じでできないかと妄想中
  52. 52. 今回は割愛しましたが、他にも色々迷ってる 、疑問も尽きない
  53. 53. けど、冒頭で疑問だった「何を満たせば DDD か教えろ」はいつのまにかどうでも良くなっ てた
  54. 54. 目的は「脱レガシー」なのだから

×