データモデル考え中

ただいま社内的に論争中なのでちょっとまとめておく

分散環境でのデータモデルはどうあるべきか
という議論。

分散環境は非同期処理が中心にはなるのだが
画面系を中心に同期処理も入ってくるので
その組み合わせを前提に考えないといけない。

基本的に外部から変更不能のタイミングが必ずある
というのが、まずは原則論にはなる。
分散処理のレイテンシーはこの先下がる一方なので
ますます使われるようにはなると思う。

その辺りを前提として
各考え方のメリット・デメリット
をまとめて置きたい。

1プロセス中心指向
プロセス・フローを中心にモデル（型）の議論をすべき
という考えかた。
フローモデルは、プロセス->プロセスが基本で
受け渡しをするエッジの部分がデータモデル的位置付け

そもそもデータモデル自体は、
黙示的に一種の振る舞いを想定するはずなので
振る舞いの記述にウェイトを置いた方が良い、
という考え方でもある。
プロセス・フローの記述とも言える。
プロセス間のインターフェイスの「型」として
データモデルを規約として設計する形になる。
型としてのデータモデルをかなり意識する形。

この辺の受け渡しの型については
http://d.hatena.ne.jp/okachimachiorz/20110820/1313843851
構造化か非構造化か、という議論はある。

[メリット]
プロセスそのものを汎化することで
業務プロセス自体の再利用性をあげることが可能になる。
モデルの練度をあげることで
データフロー自体の頑強性もあがる。
したがって、構築の投資のポータビリティが
確保できる。

さらに業務系の設計は処理を中心に
組み立てることが多いので
業務フローの汎化ができるのであれば
相当高度な設計ができる。

[デメリット]
そもそも汎用業務の設計ができる人材がいないと
だらだら不要に長い設計に堕する事になる。
これはイタイ。

あとはデータ項目の変更には
もっとも弱いとも言える。
よって何らかの拡張性を担保できる仕組みが
必要だろう。

手短な例でいうと中途半端なSOAになる危険がある。
サービスの粒度間がイマイチ＋パフォーマンス悪い
加えて変更時に対応が厳しい、というパターン。

2データ中心指向
モデル自体の状態に重きを置く設計。
フローモデルは、モデル->モデルが基本
モデルの受け渡しポイントがプロセスになる

[メリット]
なんと言ってもモデル間の整合性を取りやすい。
データ変更時点での影響度が計りやすい。
テストツールを含めて、現在のモデリングの
主流はデータ指向に近いので、道具立ては豊富。
テスタビリティも高い。

[デメリット]
まず振る舞いがよくわからないことになりがち。
どういう連携を想定していて
かつ可能なのか？が不透明になる
プロセスの練度を上げるタイミングを失うと
やたら力技になる可能性が高い。

当然の結果として、プロセスの変更に対する
見通しが悪い。
拡張性はもっとも低いと思われる。
有り体にいうと「ベタな感じでビジョンがない」

3.関数型指向
値そのものについては議論するのではなく
取得する方法について定義すれば良い。
プロセスとモデルは組み合わせの問題に還元される

[メリット]
おそらく変更に対してもっとも頑強。
再利用性も高いと思う。
データに対してはかなり透過的に扱う
形になるので、実装側が相当な変更をしても
意識されずにすむメリットは大きい。
たぶん、モデルとしてかなり本命。

[デメリット]
ただし関数の宣言的呼び出しの
順序性の整合性の確保には
かなりの理論的な強度が要求される。
本来はミドルウェアでカバーすべき。
（できるか？・・・）
粒度間の設計等は相当の高度な
技量がいると思う。

とまぁこんな感じ。
現在、考え中ですが
最終的な「品質」が鍵になると思う。

PS：
NoSQL系：ノーアイデア状態という認識
これはほぼ各所の共通認識になっていると思う。
あしからず・・・