<< ドメイン駆動設計・開発の実践 | main | 視点と観点 >>

大きな一枚岩のクラス vs. 小さなクラスのチーム

大きな一枚岩のクラスと小さなクラスのチーム


一つの大きなクラスにまとめるか、情報をもうちょっとグループ分けして、小さなクラスに分けるか?

ドメイン駆動設計は「小さなクラス」に分ける。

いや、ドメイン駆動設計だけじゃない。オブジェクト指向設計では、というか、ソフトウェアの設計の基本原則が、関心事の分離。とにかく分ける。

左は、大きな一枚岩の会員クラス。

会員を識別する情報(Entity) 、連絡するときの情報(Value)、住所の情報( Value ) という三つの関心を一つのクラスに押し込でいる。
典型的なアンチパターン。
「会員に関連する」というだけで、会員がらみの情報(属性)がこの入れ物に次々と追加され、肥大化していく。
検証ロジックや分類ロジックも膨らんできて、あっというまに見通しの悪い密林クラスの誕生。


右は、小さなクラスに分けて、それを1チームとして連携するパターン。
これだと、住所の持ち方や使い方を考えるときに、連絡先とか、会員番号とかの心配をしなくて良い。
ロジックも、住所に関するロジック、連絡先に関するロジックと、自然に分割整理できる。
図ではクラスにしていないけど、電話番号とか、Eメールアドレスも当然クラスです。( String 型ではなく、EmailAddress 型とか PhoneNumber 型 )

電話番号の入力形式や、表示形式の知識は、PhoneNumber クラスの parse() メソッドや、format() メソッドに収める。

で、これらの小さなクラスが集まって、「会員」を表現していることを、関連でモデリングする。

一枚岩のクラスよりも、豊かにドメイン知識を議論して、モデリングできる。

ドメイン駆動設計の第一歩や、こうやって、関心事ごとにクラスを分ける。関係する事柄は、関連で明示すること。

画面では、だいたい、小さなクラスの単位で、枠線を引いたり、背景色を工夫して、情報のグルーピングを明示していますよね。
その表示の構造と、クラスで表現する構造は一致しているべきなんです。

とても、簡単なことなんだけど、私にとっては、実はコペルニクス的転換というか、大きなパラダイムシフトでした。大きな一枚岩クラスでテーブルやクラスを作ることが当たり前だと思っていた。
小さく分割する、という選択肢はまったく持っていないかった。

分割することに慣れちゃうと、とても、昔の大きな一枚岩クラスにもどれないです。
問題を、小さな単位に分割すると、一見、面倒なようで、実際は、とても楽になる。

小さな問題は、すぐ解決できちゃうので、気が付くと、たくさんの問題を短時間に解決できちゃう、ということを何度も経験している。
関心事の分離は、問題解決のちょっとしたマジックです。


コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
   1234
567891011
12131415161718
19202122232425
2627282930  
<< November 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM