すごく・・・紙文化です

8
Masayoshi Hagiwara @masayh

御社は一方ではCEPとか出してインメモリでイベント処理をしているのに、別のプロジェクトでは紙文化。面白い多様性ですね。@oota_ken 「イベント」というのがトランザクション・ログという形でいろいろなものがぐちゃぐちゃに入ってしまっている点

2010-03-28 00:47:36
Kenichiro Ota @oota_ken

@masayh ええと、基本的にお客様の文化に合わせるしかない(そこまで根本的に変えるのはIT屋のできることじゃないです)ので、紙文化の世界の中でなんとかするということになっています。

2010-03-28 00:50:52
Kenichiro Ota @oota_ken

で、このモデルに対するリファレンス・インプリメンテーションの話戻ると

2010-03-28 00:52:08
Kenichiro Ota @oota_ken

プロセスがエンティティの状態を変えるのじゃなくて、いったんプロセスとして入力したものをその引数となるエンティティで分割して、そのエンティティに対して状態を遷移させるように先のプロセスを投げるとな!OO的に自然になるように主客転倒させるのか!これはすごい。

2010-03-28 00:53:31
Kenichiro Ota @oota_ken

@mkoszk なるほど。やはり業界またぎは重要なのかも。

2010-03-28 00:54:38
Kenichiro Ota @oota_ken

プロセスを主にしてエンティティを従にしちゃうとどうしてもトランザクション・スクリプトになっちゃって、むしろDOAからすら後退しているという事態。SOAであんまり考えないでナイーブにサービス設計するとそうなりがち。でも、こやつは一ひねりしている。

2010-03-28 00:56:45
Kenichiro Ota @oota_ken

僕にはテストでもアプリケーションでもアーキテクトの資質はNULLですが、スペシャリストとしてせめていけていないアーキテクチャーといけているアーキテクチャぐらいは判断できるようになりたいものです。

2010-03-28 01:07:33
鈴木三紀夫 @mkoszk

@oota_ken 「受注」の話がうまく伝わったかどうか分からなかったので、よい説明をしているサイトをさがしていました。 http://kamawada.com/~masanori/blog/2009/10/post_903.html

2010-03-28 10:32:42
鈴木三紀夫 @mkoszk

@oota_ken 「人材、設備、資金、データベースなどがストックと呼ばれるもので、それらを動かす、人事、運転、販売、購買、売上、情報共有などがフローとなります。」中略「ところで、ビジネス活動をするためのものではなく、ビジネス活動を行った結果もストックと呼んでもいいのです。」

2010-03-28 10:34:13
鈴木三紀夫 @mkoszk

@oota_ken ストックとフローという言葉遣いが気になりますが、こんなニュアンスです。僕の説明は実装方法に引っ張られた説明だったので、こちらの説明の方がより言いたいことに近いです。

2010-03-28 10:36:50
Kenichiro Ota @oota_ken

@mkoszk ありがとうございます。ただ、ストックとフローは製造のサプライチェーンベースのの話で、金融だとちょっと違うかもしれませんねー。商品自体もイベントと関連付けられてライフサイクルを持ち、商品から作られる契約も同じくライフサイクルを持ちます。

2010-03-28 12:03:04
Kenichiro Ota @oota_ken

販売管理だと通常は「売上」のイベントで終わりにしてしまうところを「売上」に「売買契約」を締結したまで関連付ける必要があるのが、金融商品に対する販売の特徴でしょうか?

2010-03-28 12:04:55
鈴木三紀夫 @mkoszk

@oota_ken 商品のライフサイクル? 商品の廃止はありますが、それ以外に状態を持つかしら。 派生商品を状態遷移として捉えています?

2010-03-28 12:05:45
鈴木三紀夫 @mkoszk

@oota_ken 僕は「契約」のとらえ方に自信がありません。ある識者はイベントと言い、ある識者はリソースだと言います。別の方は、契約はイベント・リソースのどちらでもないといいます。僕はどの言い方も一理あるような気がして分からなくなります。

2010-03-28 12:11:49
Kenichiro Ota @oota_ken

@mkoszk 持ちます。というかすごくたくさんあります。金融商品は商品の開発から実際に販売できるまで、そして廃止されるまでがすごく長いのです。そして、それ自体から派生してできるものもあります。さらに保険商品の特約のように組み合わせで別の意味を持つ複合商品も扱う必要があります。

2010-03-28 12:12:09
Kenichiro Ota @oota_ken

@mkoszk 契約はイベントとリソースの中間だと思います。イベントによって状態は変化するが、いわゆる商品のようなリソースに比べるとライフサイクルが短い。

2010-03-28 12:13:54
鈴木三紀夫 @mkoszk

@oota_ken 契約に基づいて複数の販売が行われるのか、契約と販売が一対一の関係になるのかの違いかしら?

2010-03-28 12:14:48
Kenichiro Ota @oota_ken

@mkoszk 銀行や保険においてはイベントそのものより「契約」の方がはるかに重要かつ長期的なものなので、こちらのライフサイクルを中心にモデリングしますね。イベント(入金、出金、契約締結だったり、満期書き換え等)はあくまで契約の状態を遷移させるものでしかありません。

2010-03-28 12:15:36
鈴木三紀夫 @mkoszk

@oota_ken はい。それは分かります。業務分析というと「業務フローを書きましょう」という話をよく聞きますが、金融の方では業務フローはさほど重要視されておらず、いわゆるビジネスルールを重視していると感じています。

2010-03-28 12:18:24
鈴木三紀夫 @mkoszk

@oota_ken なるほど。開発から販売までの期間を管理しているならば、ライフサイクルを持っていますね。

2010-03-28 12:19:16
Kenichiro Ota @oota_ken

@mkoszk 金融商品ではいわゆる販売というのは「契約締結」になりますので、販売そのもの概念は内部的にはないと思います。そもそも、金融商品に対しては「売買契約」ではなく「寄託契約」(だったかな?)が適用されるはずです。

2010-03-28 12:19:46
Kenichiro Ota @oota_ken

とか、なんか知ったようなことを書いてますが、一年でなんとかここら辺までキャッチアップできたことを書いているに過ぎないので、まだまだ怪しいですw

2010-03-28 12:21:07
鈴木三紀夫 @mkoszk

@oota_ken 業務知識が無いととたんに分からなくなります。お客さんが「モデル書ける奴よりも業務知識を持っている奴を入れて」というのもよく分かります。

2010-03-28 12:22:19
Kenichiro Ota @oota_ken

@mkoszk そうなんですよねー。両方を兼ねそなえている人がなかなかいないのも難しいところです。弊社はモデリングはできるけど、自分も含めて業務知識がかけている人が多いです。

2010-03-28 12:24:11
Kenichiro Ota @oota_ken

め、めんどくせええええ>例えば、請求すればいつでも払い戻しを受けられる普通預金は消費寄託の一種として、満期まで払い戻しを受けられないのが原則の定期預金は消費貸借の一種として理解することができる。

2010-03-28 12:24:29