$30 off During Our Annual Pro Sale. View Details »

CEOが愛した_ドメイン駆動設計.pdf

 CEOが愛した_ドメイン駆動設計.pdf

dowanna6

April 20, 2020
Tweet

More Decks by dowanna6

Other Decks in Programming

Transcript

  1. WHAT:コードで実現していることが間違ってる! - 例:ボタンを実装し忘れてるよ! HOW:コードの書き方が間違ってる! - 例:Promise.allしたほうがいいよ! WHERE:コードを書く場所が間違ってる! - 例:これはRepository層に書くべきじゃないよ! -

    例:これは別のClassとして切り出したほうがいいよ! - 例:これはPubSubに任せたほうがいいよ! - 例:これはマイクロサービスとしてCloud Functionsに切り分けたほうがいいよ! - 例:ここはEntityじゃなくてValueObjectとして切り分けておいたほうがいいよ! レビューコメントは3種類に分類できた 弊社のPRコメントは 6~7割がWHERE に関する指摘だった
  2. BEFORE 「責務が曖昧になって低凝集になってしまうのと、  今後変更に耐えられるよう、  インフラの実装に直接依存するのではなく、  同じ階層の抽象を経由するようにしたいです。  なのでこちらは同じ階層のどこかにインターフェースを定義して、  実装は別のファイルにおくのが良いのではないでしょうか。  階層が特に決まっているわけではないのですが、  一つ上の階層に新しく別の階層を用意しましょう。  DBとやり取りをするのはここの階層だけです。」

    「えっと、すみません、インターフェースを定義する理由が・・・」 「これは依存性の逆転と言いまして・・・」 「どうしてそれが必要なんでしょう」 「この階層の依存関係を、同じ階層に留めておきたくて」 「どうしてこの階層だけ?他の階層は同じ階層間に留めなくて良いのですか?」 「・・・あっ、大丈夫です。あとで僕が直しておきます。マージしちゃってください ^ ^」 「ヒィ」 AFTER インターフェースはEntityに、 実装はRepositoryに書きましょう。 コミュニケーションのスピードが格段に上がった 開発チームにも ユビキタス言語が!
  3. 負債を可視化できるように(後記) 質問: 「コメント数と負債は関係ないのでは?」 回答: 弊社にとって「負債」の定義 = 「開発速度を落とすモノ全て」 ・「セクシーなコードだね」「 LGTM」みたいなコメントであれば関係ないが、   弊社の場合コメントは基本的に実装ミスなどに対する真面目な指摘。問題がなければコメントは書かれない

    ・なのでコメントが多い=認識が揃っていない、ミスを生みやすい と考えた ・こうした箇所は後々もコメントが増えたり、わけのわからない設計、負債となる確率が高い ・未然に負債化を防ぐ意味も込めて、コメントが多すぎるコードは負債として扱った