<< 実践 ICONIXプロセス : メッソドはどこのクラスに? | main | 実践 ドメイン駆動設計 : オブジェクトの生成 >>

実践 ICONIXプロセス : メソッドの割り当て先のクラス

ユースケース記述を読みながら、ロバストネス図のコントロールをひとつずつ、シーケンス図のメッセージに割り当ていく。(クラスの操作に割り当てていく)

レイヤアーキテクチャと設計方針が明確であれば、この作業は比較的容易です。

私たちの場合

・画面(バウダリ)から出発する最初のコントロールは、サービスクラスのメインメソッドになる。
OrderService の submit()
 サービスクラスは、ドメインオブジェクトとリポジトリクラスに役割を委譲する。

・検証コントルールは、ドメインオブジェクトに割り当てる。
 Spring の validator インタフェースの実装ですね。

・エンティティの保存は、リポジトリクラスの save() メソッド

という感じです。

検索

検索のリクエストは、検索条件オブジェクトをつくる場合と、ドメインオブジェクトをそのまま設定条件につかう場合があります。 
find By ID のような機能は、ドメインオブジェクトをそのまま使う。
複合条件や範囲指定は、searchCriteria オブジェクトを別に用意する。
Eric Evans が DDD で説明している Specification パターンも興味があるけど、今のところ研究対象。

検索のメソッドは、リポジトリクラスに割り当てます。
findByID()
findByName()
findByDate()
...

ICONIX プロセスでは、それぞれの検索パターンごとにユースケースを記述します。(汎化はしません)
ですから、ユースケースをひとつ実装するたびに、リポジトリクラスに、findXXX メソッドが増えていくことになります。

ドメインの知識

設計方針としては、業務の知識はできるだけ、ドメインオブジェクトに集約することにしています。

会員情報に関する知識は、できるだけ MemberProfile クラスに集めるようにしている。
入力の妥当性検証ロジックとか、テキスト形式のフォーマッティングとかは、会員情報を扱う業務の基本知識ですので、これらに関する知識は、ドメインオブジェクトの MemberProfile に集めるようにする。

検証ロジックは、Validator オブジェクト、フォーマッティングは、FormatUtil という設計も過去に試したことがあります。
現在は、ドメイン(問題領域)の知識はドメイン層のクラスに集める。この方針を徹底しています。

理由は、単純に、コードの調査や変更が楽だから、ということにつきます。
ロジックと情報を一か所に集めたほうが、扱いやすい。

かっこよく言えば、オブジェクト指向らしく、ドメイン駆動っぽく、ということになるのかな?

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
 123456
78910111213
14151617181920
21222324252627
28293031   
<< May 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM