今日のつぶやき - goldenportのブログ

#simplemodeler が生成するアプリはEntityRepositoryというコンポーネントの下に永続層が隠蔽されているので、JDO以外のDataStoreを使用する、複数のDataStoreを混在利用する、といったこともできる予定。 @myen #

EntityRepositoryとアプリケーション間ではユースケースから抽出したdocumentを用いて情報を交換するので、ドメイン・モデルそのものや永続層の実装方法は隠蔽されている。 #simplemodeler @myen #

documentとentityのマッピング層があるので、ドメイン・モデルの変更からアプリケーションは守られる。 #simplemodeler @myen #

entityに従属するdocumentは #simplemodeler　が自動定義・生成するのでentityとほとんど同じ形をしたdocumentを手組みで作成する手間は省かれている。 #simplemodeler @myen #

ドメイン・モデルとユースケース・モデルがOOモデルの軸。その他のモデルはこの2つの軸に従属させて管理するとよい。この2つのビュー以外のビューは目的別に取捨選択する。 @myen #

アーキテクチャ・ビューの定番としては、Unified Processの4+1があるけど、ユースケース駆動である一方、ドメイン・ビューがないのがミスリーディングかなと思ったり。 @myen #

クラウド時代のアーキテクチャ・ビュー体系の定番はどうなるのかな。クラウドに限らず利用事例、領域の2つのビューに設計、プロセス、実装、配備の4つのビューによる4+2を基本に考えたいところだけど、クラウドになるとこれに何が加わるか。 @myen #

ドメイン・ビューにGoogleとかAmazonとかのサービスが直接入ってくることになる。サービスは設計レベルのモデル要素ではなくて、利用者からも直接見える現実世界のモデル要素として扱う。 @myen #

ソーシャルをドメイン・ビューの中でどのように扱うのかというのも論点。エンティティ・モデルだけでなくコラボレーション・モデルも定型的に扱いたいところ。 @myen #

ソーシャルをドメイン・ビューの中でどのように扱うのかというのも論点。エンティティ・モデルだけでなくコラボレーション・モデルも定型的に扱いたいところ。 @myen ff.im/bdfyv #

コラボレーション・モデルの難しい所はコラボレーションを演繹的に記述する手段がないということ。コラボレーションを抽象化したものに名前をつけて、CIM、PIM、PSMを持ちまわるのが一つの解。 @myen #

friendfeedのコメントからtwitterへの出方にクセがあるなぁ。 #

serviceとcomponentの違いは、後者が解決空間側のモデル要素なのに対して、前者が問題空間と解決空間にまたがるモデル要素であるという点にある。 @myen #

serviceとcomponentの違いは、後者が解決空間側のモデル要素なのに対して、前者が問題空間と解決空間にまたがるモデル要素であるという点にある。 @myen ff.im/bdHhk #

なんだか、friendfeedからの出方が思ったのと違うなぁ。 #

serviceの実装はserviceまたはcomponentをassemblyしたもの(今風であとmashup)というのが自然。 @myen #

service実装の組立てにはservice/component baseの糊言語が必要だけど、まだよいのがない。HTML, AtomPub, MIME on HTTPを統一的に扱うアーキテクチャの言語になるだろう。 @myen #

serviceの定義に使う要素部品がoperationとattributeのみでは、非同期・並列・分散を取り扱えない。クラウド向けにはこの点での拡張が必要だろう。 @myen #

#uml 仕様：objectのoperationの呼び出しでmethodまたはstate machineが実行される。eventの発生でもstate machineが実行される。operationとeventの関係はどうやら未定義。 @myen #

#scala にbreak入るとうれしい。手続き脳なので。『Onion開発再開しつつある日記』 ff.im/bdMTx #

[活動]要求開発とPDC ff.im/beLy8 #

Automatically shipped by LoudTwitter