構造設計の良し悪し | システム設計日記
Domain-Driven Design(DDD)の１６章の最後の数ページは、パターンとして定義してないけど、構造設計について、興味深い内容が書かれている。 構造設計の良し悪しの判断？ ソフトウェアは、バグがあったり、性能問題が発覚すれば、開発チームのメンバーは、みんな問題だと思うし、修正しようと思う。 そして、直ったか直らないかは、いちおう確認できる。 構造設計になると、そうはいかない。 ソフトウェアがちゃんと動いていて、ソースの中身も、まあまあ、追いかけることができれば、全体の構造なんて、あまり気にしない技術者、チームが多いのかもしれない。 クラスが肥大化して、参照関係が入り組んできて、コードが読みにくくなり、修正の副作用が恐くなってくると、さすがに、これじゃまずい、という「感覚」はでてくる。 ファウラーが「リファクタリング」で書いているように「コードのいやな臭い」を感じる度合い、感じ
System Metapher パターンなんて、使うべきじゃない！ | システム設計日記
Domain-Driven Design の１６章「構造」では、システム全体を、表現するテクニックとして、System Metapher パターンをあげている。 私は、メタファーテクニックは、賛成できないなあー。 エバンスも、 ■ 使えるプロジェクトは、多くはない ■ メタファーは、しょせんは、本来のモデルではない借り物 ■ メタファーを使う価値をプロジェクトの途中で、みなおすべき ■ メタファーの弊害に気が付いたら、メタファー利用を停止すべき ... てな感じで、注意点を並べている。全体として、否定的なトーンを感じる。 Fire Wall DDD では、ネットワーク上の Fire Wall ソフトウェアを、System Metapher が役に立っている例としてあげている。 イメージはぴったりかもしれない。 使うべき時 業務のプロが、使っているメタファーは、そのままドメインモデル、ユビキ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blogs.sun.com/nishigaya/entry/domain_driven_design_quickly
