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

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

2012 04 新卒入社ど素人
１年くらい多重度をフランス語だと思ってた（→タジュード）
社会人歴の半分くらいは php でフロントエンド、
後半の半分くらいは Java / DDD をやっている
ここ１年ちょっとはテックリードみたいなことも
ScalaMatsuri 毎年行ってます、 Haskell Day も行ってみた
よ
最近認定スクラムマスターになりました
最近はテスト系の勉強会とかに乱入したりもしています
自己紹介

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

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

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

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

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

しかし！
初学者がこんな指示でものづくり出来るはず
がない
DDD ってのが何を言いたいのか、みんなが僕
に何をさせたいのか、全くわからない
フレーズが先行してた感じが強くて、抵抗が
すごかった …フレーズ駆動開発とでも言う？

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

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

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

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

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

絵にする
描く

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

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

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

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

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

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

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

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

→ 処理順とか永続化処理が全部集まったけど、辛い…
→ 巨大な void 申込() が１つだけならありますけど…
→ ？？？
→ ？？？

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

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

動詞を探す
ピックアップ

void を排除したいのでインパラ→「メソッド名」→アウトパラの形にする
メアドと年齢と住所とプ
ランとスマホ→「申し込
む」→？？？
未成年→「申し込めない
」→ ？？？
本州以外→「必要になる
」→ ？？？
まだ日本語で整理

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

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

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

→ ドメインクラスが何に依存して何を算出するか、その整理のこと
、っぽい
→ ドメインクラスを算出するメソッド名のこと、っぽい
→ Domain 層から処理順やデータアクセスを排除して上記２つの算
出に集中しようってこと、っぽい
→ 最初の文書には明記されていない単語がある、っぽい

とは言え、void じゃあないもの全てがドメイン
なわけでもないだろう
ドメインか否かの境界線があるはずだ
それに、膨大な企画書や広大な Domain 層を見
ても隠れている単語を見つけるなんて無理だろ
う
ドメインの中にも境界線があるはずだ

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

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

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

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

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

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

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

→ ドメインクラスが何に依存して何を算出するか、その整理のこと、っぽい
→ ドメインクラスを算出するメソッド名のこと、っぽい
→ Domain 層から処理順やデータアクセスを排除して上記２つの算出に
集中しようってこと、っぽい
→ 最初の文書には明記されていない単語がある、っぽいので範囲を絞っ
ておくと考えやすいし変更しやすいってことだ

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

再掲
→ ドメインクラスが何に依存して何を算出するか、その整理のこと
→ ドメインクラスを算出するメソッド名のこと
→ Domain 層から処理順やデータアクセスを排除して上記２つの算
出に集中しようってこと
→ 最初の文書には明記されていない単語がある、なので範囲を絞っ
ておくと考えやすいし変更しやすいってことだ

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

〜おまけ〜
§7 東京のあと考えたこ
と

東京開催の時のパネルディスカッションで「
テストコード要らないんじゃね（概訳）」って
話があった
（超乱暴にまとめると）手続き実装や型なし言
語だとテストたくさん必要だけど、型があれば
テストは減らせる / 要らない

そう言う面もあるのは賛成
けどいろんな人が参加してる中で前提を揃え
ないで言うのは勘違いを誘発すると思う
悶々と考えてたけど、やっぱり僕は「
書くべき派」なので、今更だけど正面からア
ンチテーゼをぶつけたい
ちょっと待って

コンパイルしたって抜けないバグは山ほどある / ドメ
インクラスがあれば無条件で型の恩恵が得られるわけ
ではない
本気で実行時例外をなくす様に考えて作ってる？
テストコードが最初のそのドメインの利用者なので、
違和感や使い辛さとかに気付くチャンス
引数多くて辛いなぁとかモックサーバがないと動かないとか、そうい
う味見を放棄しているまさに学ぶ瞬間なのにもったいないよ！
リファクタリングの促進のためにも、あってほしい
理由

別にカバレッジ 100% しか認めないって言ってるわ
けではない
戦略的に減らそう、材料はたくさんあるはず
もう少し詳しく書いてみた -> 型がある言語で DDD
してたらテストはいらないの？
https://qiita.com/suzuki-
hoge/items/127836df5ba57a13c94e

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

設計時点でレイヤー毎に起きるエラーを限
定する
だって起きる理由もその後の対処も違うか
ら
特にシステムのエラーとビジネスのエラー
は絶対に分けたい
できるだけ型情報にして図示する、極力例
外を使わない、コンパイルの恩恵を大きく
する
本気で実行時例外をなくす
フィードバックサイクルを早くするために
、当然テストも書く
エラー設計をこんな感じでできないかと妄想中

今回は割愛しましたが、他にも色々迷ってる
、疑問も尽きない

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

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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Empfohlen

Empfohlen (20)