インターフェース設計のトレードオフ

dev SOA

鈴木雄介さんのBlogより。
SOAから学ぶアプリケーションレイヤーの統合 (arclamp.jp アークランプ)

もっとアプリケーション設計寄りで言えばDAOのパラメタオブジェクトをあげても良いでしょう。UserDaoのメソッドsearchを定義するなら、引数はクラスUserSearchRequestとします。こうすれば検索条件が増えたとしてもクラスUserSearchRequestの属性を変更するだけでよいわけです。

　もちろんインターフェース設計はどうでもいいということではありません。ビジネスロジック層へのアプローチがすべてパラメタで処理されるとなると、それはそれで柔軟すぎて複雑になってしまいます。適度にドメイン分割をすることが必要です。とはいえ、ここの適度感は非常に難しく未だに的確な分割方針を聞いたことがありません。

そうそう、その通り！このあたり、漠然とした問題意識は持っていたのですが、このようにきちんと問題として定義できていませんでした。
余談ですが、オブジェクト指向を使いこなせるかどうかは、ここの設計スキルに大きく左右されているように思います。学生の頃にFortranでやたら引数の多いサブルーチンとかを作って辟易してましたが、Javaを使うようになって「どのように引数をグループ化(=オブジェクト分割)するか」ということを強く意識するようになりました。

余談ですが、個人的にはインターフェースが「システムの見える化性」からもデザインされるべきだと感じています。インターフェースはシステムの監視ポイントです。メッセージの意味まで解釈して監視するのはけっこうめんどうなのです。遠い例ですがWebサイトのディレクトリ設計（ようはURL設計）をアクセス解析のために行うようなものです。あとで理解しやすいようにURLが取得されていないとアクセス解析しても意味が分かりません。解析ができれば対応を行うことができます。これはスケーラビリティやメンテナンスビリティなどの要素に大きな影響を与えます。

この例えは秀逸ですね。
インターフェースが適切に分割されていないWebサイトでは、ある特定のURL(サーブレットなど）にパラメータを与えることで全ての機能を実現したりしていますが、アクセスログの解析が困難だったり、場合によっては不可能（POSTだとログに残らない）だったりします。
Servlet Filterが導入される前は、アプリケーション全体の挙動を制御するために入り口を絞る必要があったので、こういうつくりを採用することがありました。また、ポータルサーバーなどはアーキテクチャ上の必然性からこういうつくりになってたりします。
これに対するアンチテーゼとしてRESTが提唱され、Web2.0のコア技術として使われているのは面白いですね。