Domain-Driven Design(DDD)の16章の最後の数ページは、パターンとして定義してないけど、構造設計について、興味深い内容が書かれている。 構造設計の良し悪しの判断? ソフトウェアは、バグがあったり、性能問題が発覚すれば、開発チームのメンバーは、みんな問題だと思うし、修正しようと思う。 そして、直ったか直らないかは、いちおう確認できる。 構造設計になると、そうはいかない。 ソフトウェアがちゃんと動いていて、ソースの中身も、まあまあ、追いかけることができれば、全体の構造なんて、あまり気にしない技術者、チームが多いのかもしれない。 クラスが肥大化して、参照関係が入り組んできて、コードが読みにくくなり、修正の副作用が恐くなってくると、さすがに、これじゃまずい、という「感覚」はでてくる。 ファウラーが「リファクタリング」で書いているように「コードのいやな臭い」を感じる度合い、感じ