まとめ
メニューを開く-
CoreBanking Renovation Framework...., これが真のMDDのなのか！いきなりビジネスエンティティのライフサイクル分析から始まる！僕がやりたかったのはこれか！さらばExcel方眼紙！ -
http://bit.ly/cyyeUP こやつを勉強中です。
-
COBOLはクラウド時代でも生き延びるとは恐ろしい・・・エンタープライズ向けがでてきたらまあサポートするところもでてくるよね。でも、それってIaaSどまりであんまりうれしくないよーな。
-
正直、固定長フラットデータ電文というCOBOL脳の人と話すのは激しく疲れるんだけど、まあ、お客様もそれベースで話すのでユビキタス言語なんだと思ってそっちに歩みよろうともがいてます。
-
だめだ！COBOLのこと考えるとつらくなってくるｗ 理想のモデリング世界に逃避しよう・・・
-
ふむ、エンティティーまたぎのロジックはルール・エンジンにぶち投げるのか。変に責務をどちらに寄せるとか、OOではない新たな概念を持ち込み出すとかじゃなくてこれはこれでありかも。でも、これなんてDOA?多分、ルールの部分が実際のビジネスユーザーに認識できる単位というところが違う。
-
ビジネス・プロセスと同じにそのビジネス・プロセスで使用するビジネス・エンティティのライフサイクル分析をする。
-
というか、ビジネス・エンティティのライフサイクルからビジネス・プロセスを見る。ビジネス・エンティティごとにビジネス・プロセスのライフサイクル分析をして、ビジネス・プロセスでマージする。
-
これは、プロセス先行でデータがおざなりになりがちなSOAの開発プロセスを補完する良い方法だと思う。ていうか、OO的にはこっちの方が自然だ。
-
今の参照モデルだとイベント(トランザクションと考えてよい)自体もエンティティとしています。
-
普通預金口座に入金するのようなトランザクションの場合、単に口座の残高を帰るだけでなく、「入金」自体もイベントエンティティとして「こと」を記録するために永続化対象になります。
-
今のお客様だとこの「イベント」というのがトランザクション・ログという形でいろいろなものがぐちゃぐちゃに入ってしまっている点でこのモデルを使って、もっと概念を切り分けたいなあと思っています。
-
ビジネス・プロセス上に出てくるビジネス・エンティティを分析するというのはOOな人や海外のSOAプロジェクトでは普通らしいのですが、どうも日本の金融のお客様ではそもそもそういう発想がないのかな？状態遷移モデルは組み込マーには普通でもエンタープライズ系では異端？
-
Content from Twitter
コメント