メモ – コンポーネント指向とサービス指向
コンポーネント指向
いろいろな定義があるが、簡単に言うと「部品をたくさん作っておいて、それらを組み合わせてシステムを構\築すること。」である。
サービス指向
機能やアプリケーションなどをサービスとして捉え、組み合わせて利用すること。最近注目のWebサービスもサービス指向。
まとめ
従来より利用されてきたコンポーネント指向では、部品化の単位がプログラム機能などの細かい単位であるのに対し、サービス指向ではXML、SOAPなどのシステムの基幹となる機能を単位とすることが特徴。
メモ – 例外
階層分離開発における例外設計
階層分離開発では深い層で発生した例外は、それより浅い全ての層を通過する。つまり、どの層でもキャッチすることができるということである。
層を跨（また）いで受け渡されるデータは、うまく設計しないと後々システムに混乱をもたらす。一度設計が破綻すると、むりやりツギハギをあてるか、または多大な修正コストを費やして丸く収めなければならない。
層を跨（また）いで受け渡されるデータは、うまく設計しないと後々システムに混乱をもたらす。一度設計が破綻すると、むりやりツギハギをあてるか、または多大な修正コストを費やして丸く収めなければならない。
階層分離開発では、サービス層で発生した"サービス例外"はプレゼンテーション層でキャッチするように統一することで、比較的綺麗な構造になる。ビジネスロジックも多大な例外処理を考慮する必要が激減する。例外発生時の動作も変更に強くなる。
例外処理の統一
テストのカバレッジ向上作業を行っていて気づいたのだが、例外に対する処理が開発者によって異なっている。
ある人は、想定外の例外(データ不備によるNullPointerExceptionなど)をすべてキャッチし、サービス層の例外を再throwしている。
try{
// 略
}catch(Exception e){
throw new ServiceLayerException(e);
}
また別の人は、想定外のケースに対応したりしなかったりしている。要するに、自分のコードですら統一されていない。理由はわからないが、おそらく思いつくままにコーディングした結果だろう。
String id = dao.getId();
if(id == null){
throw new ServiceLayerException("id not found");
}
String name = dao.getName(id);
// 上記のような処理は無し。
例外戦略はコーディング基準同様、プロジェクトで統一されていなければならない。
バラバラに実装された例外処理の統一化は、リスクを伴う多大なコストがかかる。
メモ – 階層分離開発
階層分離開発
図１：ほぼ失敗しない最近の階層分離
最近はこんな感じで設計している。
層を完璧に分離しているので、作業を分担しやすい。
層を完璧に分離しているので、各層ごとに単体テストを実行できる。
層を完璧に分離しているので、コードを追うのが楽。
いいのか悪いのかわからないけれど、いろいろな場所でサンプルアプリケーション見てると似たようなパッケージ階層になっていたりするのでちょっと安心。
あとは例外設計がきちんとできれば○。
プロフィール
@hacker634
へなちょこシステムエンジニア。Java,PHP,C#,JS,Objective-C,DB,なんでも好きです。ヘビーな言語もLLも全部好き。SIer→受託屋→フリーランス→ちびっこWEB開発会社勤務（いまココ）担当は、ディレクション、アーキテクト、設計、開発、テスト、保守、研究、雑用、デザイン。つまり、なんでも屋。 Follow @hacker634-
リンク
