「Don't call us. We'll call you.」 ダイコン時代になると役者がプロデューサーを呼び出さないのは もちろんのこと、プロデューサーも役者を直接呼び出したりはしません。 企画書(ダイコン定義ファイル)に書いてある役(インターフェース)を 演じる(実装する…

ダイコン時代のアーキテクチャでは、各層がきちんと 役割分担をすることが重要だと書いたのですが、 それは、Validationにももちろん当てはまります。 各層でどのようなValidationを行うのかを きちんと決めておく必要があります。 Validationはつぎのような…

http://d.hatena.ne.jp/skimura/20040610#1086860610より コンポーネント間はインターフェースで結合されます。 それは、設計書も実装も同様です。 1つのインターフェースに1つの実装クラスしかない場合は、 依存関係はダイコンによって自動解決されるので、…

この番組は、あなたのダイコン脳を活性化させます。 今日の問題は、id:makotanさんの出題です。 http://d.hatena.ne.jp/makotan/20040611#p2 HogeAimpl extends HogeA HogeBimpl extends HogeB のどちらにもダイコンファイル名が埋め込まれています。 HogeBi…

UI層のモデルはエンティティ(ドメインオブジェクト)ではない。 間違いない UI層のモデルは画面の入出力のための一時的なデータの入れ物であり、 決してエンティティではないと思います。 これは、画面でしか使わないような一時的な項目もあることから 明らか…

そうなのかっと感心するとともに、実は当惑…。データとそのデータを扱う処理をひとつのものとして扱うのがオブジェクト指向設計であり、保守を容易にするにはそれを目指すべきだと思い込んでいました。 関連のあるデータと振る舞いを1つに集めることで、 凝…

例外のログをどの層でとるべきなのか。例えば、DAO層で発生した例外は、サービス層、プレゼンテーション層も通ることになり、基本的にどの層でもcatchすることはできる。 例外のログを書き出しは、次の場所が考えられると思います。 例外をthrowするクラス …

モデリングは、 振る舞いのモデリング データモデリング に分けられると思ってます。 振る舞いのモデリングは、ユースケースを ユースケース固有のロジック 共通のロジック データアクセスのロジック にブレークダウンしていくものです。 今回のテーマはデー…

例外処理は、throwする側とcatchする側に分かれますが、 最初はcatchする側について。 catch禁止。間違いない。 個々の開発者に例外をcatchさせるとろくなことにならないというのが、 私の経験則。 例外は、原則、サービス層でcatchすることなく プレゼンテ…

スタラジで、本来話したかったことをまとめておきます。 最初はユースケースからスタートします。 本当は、RFPをユースケースに落とすという工程が 前工程にあります。 ユースケースの粒度について神経質になると 失敗します。 画面系ならいくつかの関連のあ…

ダイコン時代のアーキテクチャは次のようになると思っています。 UI層、サービス層、永続化層、エンティティ層(ドメインオブジェクト)で構成される。 UI層はUIのフレームワーク(Struts, Tapestry等)に依存する。 永続化層の実装はO/Rマッピングのフレームワ…