Posted at

DRY & DDD

More than 1 year has passed since last update.


tl;dr


  • 「DRYではない」みたいにドヤ顔でレビューしてくる人とかいるけどエヴァンスさんもこう言っているんだから常にDRYなコードなんてかけないでしょ


Don't repeat yourself


Don't repeat yourself (DRY) あるいはSingle Source of truth(英)[要出典]は、特にコンピューティングの領域で、重複を防ぐ考え方である。この哲学は、情報の重複は変更の困難さを増大し透明性を減少させ、不一致を生じる可能性につながるため、重複するべきでないことを強調する。



  • レビューでコードやロジックが重複している場合によく「DRYではない」みたいに使われる


常に DRY でいられるか


  • DRY にこだわることにより早すぎる最適化や誤った抽象化を行ってしまう可能性があるので常に DRY でいる必要はないと思っていた

  • 伝わる人には伝わるが DRY 原則を絶対視する DRY 原理主義者が相手だと弱い


そこで DDD


  • エリック・エヴァンスのドメイン駆動設計を読んで DRY 原理主義者に立ち向かうロジックができた気がするのでまとめてみる


DDD について簡単に


  • 複雑な問題領域(ドメイン)をよりよく解決するモデルをつくり、それを出来得る限りそのままコードで表すことでシステムの複雑性をコントロールしようという設計手法

  • はじめから完璧なモデルができるということはなく、ビジネス側のドメインに詳しい人(ドメインエキスパート)と協力してリファクタリングを繰り返しながらドメインについての理解を深めていくことでより良いモデルとコードをつくりあげていく


DRY 原理主義者に DDD で立ち向かう


  • ソフトウェア開発においてドメイン駆動設計を行うか行わないかにかかわらず、実装中のドメインについての理解の浅い段階というのは常に存在する

  • 常に DRY であろうとすることは、理解の浅い段階でも常に正しいモデルを実装できるという誤った前提に立つものであり無理がある

  • DRY であろうとすることは良いことだが、常に DRY でなければいけないという態度は単なる思考停止である

  • 常にすべてを見通せる知識を持つわけではない私たちは、常に DRY ではありえないことを謙虚に認め、より DRY であることを目指しながらこつこつとソフトウェアを開発していくしかない


さいごに


  • もちろん明らかに構造化できるのにコピペしていたらドヤ顔で「DRYではない」ときめていい

  • が、DRY ではありえない場合もあることを認めて自分にも同僚にも優しくなることで楽しく開発をしていけると幸せ