大西彰のウェブログ

# re: データベースとビジネスロジック 2005/09/23 6:05 河端善博

興味深いロジックですね。
PDC 05 でも、さまざまな実装が公開されていたのではと思います。
※私はホスティングの観点からIIS,WCF,WWF を中心にセッションに参加していたので。

さて、今回の PDC 05 に参加して、Windows Workflow Foundation / WWF, Windows Communication Foundation / WCFが出てきてきたことを、見た上でビジネスロジックの配置について、次のように考えています。

ビジネスロジックは、.NET のクラスとして実装する。
このクラスの内部実装では、RDB に任せられることは、ストアドまたは、SQLCLR で実装する。

理由は、ビジネスロジックに必要とされる要件・機能には、リレーショナルデータベース以外にも、さまざまな要素が要求されているからです。
今後、データベースについても、RDB だけでなも、DMX, MDX を使って多様なデータソースから情報を引き出しつつ処理すことで、より拡張性があがりますし、WWF, WCF をヒジネスロジックに持ち込むことで、柔軟性、拡張性が高くなるでしょう。

したがって、基本 .NET クラスとし、Foundation として ストアド、トリガ、RDB, MDX, DMX, WWF, WCF ... としようと考えています。
もちろん、LINQ をつかっての、ロジック開発も進みそうですしね。

# re: データベースとビジネスロジック 2005/09/23 9:24 中博俊

おそらく明快な解はないです。
それどころか複雑さは深まる一方だと思います。

Jのように簡単な世界でない以上そのアプリケーションごとの切り分け方を模索する必要があるのではと思います。

SQLCLRは一つの解になりますが、いわゆるプログラムロジックの複雑なバッチ処理というものの選択肢が増えたということでしょう。(^^

# re: データベースとビジネスロジック 2005/09/26 11:26 大西　彰

河端さん、中さん、コメントありがとうございます。

いろんな見方があるように感じました。私自身も継続して模索してみたいと思います。技術的な選択肢が増えるのはエンジニアとしては興味深いのですが、実際のシステム開発において自由度が高いのは、長期にわたるアプリケーションをライフサイクルを考えた場合に、戦略を決定するのを難しくするようにも思います。

どんな開発に対しても正解がひとつということはたぶん永遠にないのかもしれませんが、システム開発毎に最適な解というのはあり得るかもしれません。長期のテーマとして、取り組むほかないのかなぁ(^^;

# re: データベースとビジネスロジック 2005/09/26 12:12 佐藤剛宣

はじめまして。
ビジネスロジックをどこに置くか。全く同感です。ドメインモデルと一口に呼んでも、ビジネスロジックを含むかどうかというのはものすごく個人差があるように感じます。

ユースケースに応じてビジネスロジックは変動するけれども、データモデル自体は変動しないことが多いので、依存性の観点から切り離すべきだという主張には、普遍性があって好きなので、私はこのタイプです。

一方いわゆる天才プログラマは、がっちりビジネスロジックとデータモデルに組み込んで非常に効率的なアプリケーションを作っているような気がします。

# re: データベースとビジネスロジック 2005/09/26 14:02 大西　彰

佐藤さん、コメントありがとうございます。

なかなか難しいテーマなのですが、システムを全体最適するか、部分最適するかによっても、ロジックをどこにおくのかという戦略が変わってくると考えています。

長期的なIRM (Information Resource Management)の観点で考えると、データそのものの保護を長期の観点で考えていく必要があり、ビジネスロジックも普遍性のあるものと揮発性のあるものとにわかれ、その見極めは、DBA (Database Administrator)と開発者が協調して行わないとうまくいかないと思います。ところが、日本でのシステム開発の場合、多くはDBAという職種と連携した設計ではなく、開発者主導のデータベースとビジネスロジックの設計になってしまい、属人性が高くなる可能性が否めません。

なんにせよ、効率性は重視しなければならないし、システムの品質は高めなければならないし、開発者もDBAも課題が山積になるのでしょう。良い意味での妥協が求められる時代なのかもしれません。（←結論になってない ^^;）

# re: データベースとビジネスロジック 2005/09/27 0:44 佐藤剛宣

「場合による」というのが現実的な結論でしょうか・・・。

それでも、ポリモーフィズムと継承をうまく活用することで、うまくバランスを取って標準化できないかと考えています。継承はRDBMSで実装が厄介だと思うので、ODBMSの話になってしまうんですが、データモデル/ビジネスロジックを普遍性や揮発性などの変更可能性に応じて、継承構造を作りそれぞれをドメインモデルとしてコンポーネント化していきます。普遍性のあるものは、ロジックを組み込んでしまうembedded方式で、揮発性の高いものはfaçadeのように外に出すmanager方式で実装します。こうすると普遍性の高いものの再利用性と性能を向上し、揮発性の高いものは最小のコードで必要に応じて用意に追加変更ができそうに思えます。

これはMichael Blahaさんの意見で、RDBMSのモデリングでは考えもしなかったことなので、大きな可能性を感じるのですが、大西さんはどう思われますか？

# re: データベースとビジネスロジック 2005/09/27 14:40 大西　彰

佐藤さん、興味深いご指摘ありがとうございます。

ODBMSの場合、
・普遍性のあるビジネスロジック => 組み込み
・揮発性の高いビジネスロジック => FacadeとStrategyパターンの組み合わせ
で実装するのがよいと考えています。ほぼ同意見ですね。

RDBMSの場合、上述と同様のことを実施するには、オブジェクトモデルとデータモデルとのギャップを埋める必要があり、R-O、O-Rマッピングの問題が生じます。RelationalとObjectのマッピングにはいろいろ方法があり、手作業からツールを使って行う方法まで、好きなものを選択すればいいかと思います。RDBMSを永続化のストレージとして割り切ってしまえば、データベースの外側でのオブジェクトモデルでソリューションを組み立てればいいと思います。もちろん、ストアドプロシージャなどを利用することを反対しているのではなく、オブジェクトから見たときに、ストアドプロシージャが実行されていることを意識しなくても済むような構造で実装すればいいという話です。

コメントに図を入れられないので、ニュアンスがうまくつたわるかどうか心配なのですが…。

# re: データベースとビジネスロジック 2005/09/27 19:21 佐藤剛宣

同意見でよかったです。もっと研究してみます。
RDBMSでもODBMSでも、これらをいかにシンプルに実装できるかが、残りの課題ですね。

“I don't make things complicated. That's just how things get all on their own.”
Martin Riggs, Lethal Weapon

・・・とかく何事も複雑になるようなので。

# re: データベースとビジネスロジック 2005/09/28 17:07 大西　彰

リーサルウェポンは、私の大好きな映画のひとつです(^-^)/
単純化というか簡素化というか、シンプルなのが一番ですね。

# re: データベースとビジネスロジック 2005/10/06 11:30 Yoshihiro Kawabata/河端善博

いま、SSIS のチュートリアル本を日々読みながら、開発担当の Kirk にメールを出す内容を考えてもいます。
変化に対して、ITPro レベルでの柔軟な対応が求められるロジックは、SSIS がとても有効。その延長に WWF.
さて、SSIS/WWF は、URL,O/R,ORDBMSなどの議論のどこに位置づけられるのだろうか。

# re: データベースとビジネスロジック 2005/10/08 1:56 大西　彰

私という個人的には、SSIS,WWFの位置づけは現時点でうまく表現できないですね。ワークフローの中で動かせるものの粒度が柔軟であるのがその理由のひとつです。
近い将来WWFがOSに標準搭載されることにより、開発者はワークフローの実装において、開発プロセスを標準化しやすくなるとは思います。ただし、ワークフローも小さなものから、ビジネスプロセス全般にまたがる横断的な大きいものまであるわけですから、今後、BizTalkとWWFとの棲み分けがどうなるのか、この議論はSOAを持ち込んでこないといけないかもしれないですね。PASSJのカバー範囲を超えているかも(^^ヾ

# 1年1ヶ月経過して 2005/10/20 22:21 大西彰のウェブログ

1年1ヶ月経過して