« 機能タイプ&テーブルポジションで効率アップ | トップページ | テーブル操作と業務ロジックの連動制御 »

2016.01.28

業務ロジックをアプリに置いてはいけない

 業務システムを純然たるソフトウエアとして見た場合、テーブルとアプリ、そして「業務ロジック(ビジネスルール)」の3つの定義要素の組み合わせとしてモデル化できる。この中の「業務ロジック」の配置様式は、システムの開発・保守効率に決定的な影響を与える。

 業務ロジックとはどういうもので、それはどのように配置されるのだろう。たとえば「注文テーブル」に「XXX数量」があるとして、その「初期値」が1000であるとしよう。素朴ではあるが、このルールも業務ロジックの一種である。これがどのように配置されるかというと、ふつうは注文テーブルのCreate文のDefault句として組み込まれる。

 「初期値」だからといって、Default句で対応できるとは限らない。実際には「YYYが'A'の場合は1000だが、YYYが'B'の場合は0を初期値とする」といった条件をともなうことがある。さらに、「YYYが'C'の場合には、関連するホニャララ明細のZZZを集計した値を初期値とする」といったテーブル操作を伴うこともある。こうなると、DDLでは対応できない。

 そのように比較的複雑な業務ロジックがどのように配置されるかというと、たいていは「アプリ」にハードコーディングされる。しかし本来はそうすべきではない。

 なぜか。一般に、1個のテーブルに注目した場合、それを操作するアプリは1個とは限らないからだ。たとえば、注文テーブルにレコード追加するアプリが、構内のPC用アプリの他に、スマホのネイティブアプリや、EDIアプリとしても存在するかもしれない。それらの異なるサーバ上のアプリに、いちいち「YYYが'A'の場合は1000、YYYが'B'の場合は0、YYYが'C'の場合は関連するホニャララ明細のZZZを集計した値を初期値とする」と記述するのは「正規化違反」である。重複しているゆえに、保守の過程で不整合が生じる可能性があるからだ。

 項目値を設定するためのルールに限らない。「妥当性検査」や「テーブル操作にともなう関連テーブルの操作」等、「アプリではなくテーブルに従属する業務ロジック」にはさまざまなものがある。これらがいちいちアプリ側に重複的に記述されている――それが多くのシステムの残念な実態である。

 では、それらを「テーブル側の業務ロジック」として一元的に配置するにはどうしたらいいのか。基本的には「トリガー」のような機構を使えばよい。テーブル操作の前後に実行されるべきスクリプトとしてまとめることで、業務ロジックをアプリから切り離せるからだ。

 ところが、トリガーには使い勝手の悪さがつきまとう。スクリプトが実行されても、その結果が、テーブルを操作している機能自身のプログラム域と連動しない。他にも、RDBMS毎に記述様式が異なっているなど、悩ましい制約がいろいろある。

 そこで求められるのが、実行基盤が提供する「自前のトリガー機構」である。たとえば、テーブルTを更新する機能Fが実行されたとしよう。そのとき、「Tの更新前に実行される業務ロジック」として登録されているスクリプトを、RDBMSではなく基盤自身が起動する。さらにその結果が機能Fのプログラム域に反映されたうえで、制御が機能Fに返る――そのような基盤側の機構があればよい。さらに、その種の業務ロジックが「テーブルの拡張定義」として示されるようになっていればもっとよい。

 業務ロジックをアプリ上に直接書くか、テーブルの拡張定義とするか。その違いは、アプリと業務ロジックの「バインドタイム(結合のタイミング)」の違いとして説明できる。業務ロジックをアプリ中に記述するやり方において、バインドは「コーディング時」になされる。いっぽうの、アプリの実行時に業務ロジックを読み込んで統合するやり方では「実行時」である(*1)。

 「コーディング時バインド」のほうが、一般にレスポンスが良好である。アプリの実行モジュールに、業務ロジックが最適化された形で格納されるからだ。いっぽう「実行時バインド」のシステムのほうが、可読性・保守性が良好である。業務ロジックが独立した定義要素であるため、都合の良い体系でそれらを維持管理できるからだ。

 一長一短あるとはいえ、ハードウエアと人手の単価の差やハードウエアの性能向上速度のことを考えたら、システムの可読性・保守性を優先させるべきことは明白である。バインドタイムを遅らせることで、アプリは「業務ロジックを含まない薄っぺらな定義要素」に縮退する。開発・保守コストの大部分がアプリを対象とする作業に充てられていることを思えば、その意義は大きい。

 じっさい、業務ロジックが切り離されてアプリが薄っぺらになると、アプリの開発は想像以上に楽になる。「業務システム向けのデザインパターン」の記事で説明したように、多すぎず少なすぎない処理パターンを想定すれば、パターン毎の可変部分を記述するためのDSL体系とそのエディタおよびインタプリタを構成できる。個々のDSL記述はエディタによって「仕様書」として示せるので、まさに「そのまま動く仕様書」としてアプリを宣言的に記述できるようになる。結果的に、設計工程と実装工程とが融合して、プログラミングの専任要員が要らなくなる。

 なお、業務ロジックの中には、どうしてもアプリ上に記述せざるを得ないものがある。そのような業務ロジックは、いわゆる「バッチ処理」上に置かれている。バッチ処理とはUIを伴わないアプリの一種で、一般に複雑なロジックで大量のデータを処理する。その種の仕様も「データの扱われ方」という意味で業務ロジックに分類できる。すべての業務ロジックがアプリから独立した形で記述できるわけではないということだ。

 とはいえ、バッチ処理以外のアプリが「業務ロジックを含まない薄っぺらな定義要素」として類型化・様式化されるだけでもじゅうぶんに意義深い。厳密には、いかなるアプリであっても業務ロジックの一部であると言えないこともない。しかし、類型化・様式化されたアプリというものは、たとえそれが業務ロジックの一種だとしても、設計・開発・保守にかかるコストが圧倒的に小さい。その余力で、バッチ処理を含めた全アプリを設計者自身で実装できるようになる。

 「モデル=テーブル+業務ロジック」とみなして、この議論を「MVCアーキテクチャ」の話として納得してもらってもかまわないのだが、私の意図は少し違う。システムに含まれるさまざまな定義要素のうち、バッチ処理までを含めた業務ロジックについては、手続き的に丹念にコーディングされる必要がある。しかしそれ以外のModel、View、Controlerの諸要素については宣言的に記述できるようなDSP(ドメイン特化基盤)が想定可能という話なのだ。DSPを用いると、システム記述をまとめる過程でOOP(オブジェクト指向プログラミング)の出る幕はない。けっきょくOOPにとって個別案件開発は役不足なのであって、その偉大なパワーはDSPそのものの開発に充てたほうがいい。

 まとめよう。業務システムの基本構造は、「DB構造」と、DB構造に沿って格納されるデータの整合性を維持するための「業務ロジック」とで規定される。それらさえしっかりエンジニアリングされていれば、「アプリ」の開発は工夫次第でどんどん楽になる。その意味でアプリは、生成と消滅を繰り返す泡沫(うたかた)のようなものだ。そういうものに手間をかけてはいけないし、大切な業務ロジックをその上にハードコーディングしてもいけない。


*1.コーディング時と実行時の中間は「コンパイル時」である。「コンパイル時バインド」と「実行時バインド」を比較すれば、レスポンスにおいては前者、定義とコンパイルオブジェクトとの異同の心配がないという意味で後者に利点がある。

|

« 機能タイプ&テーブルポジションで効率アップ | トップページ | テーブル操作と業務ロジックの連動制御 »

コメント

たびたび質問させて頂いています。
今回は、「業務ロジックをアプリに置いてはいけない」について質問させてください。
三要素分析法の書籍はほとんど読ませていただきましたが、アプリと業務ロジックの分割は、三要素分析法では現れていないように思います。これは、詳細設計のタスクになるものでしょうか。だとすると、X-TEA Driverで設計する対象ということになりますか?
申し訳ありませんが、ご意見を頂けたら感嘆です。
宜しくお願い致します。

投稿: くまきち | 2017.11.22 20:33

ここらへんは設計方法論ではなく、実装基盤のあり方の問題ですね。したがって、言われるように詳細設計で考慮されます。業務ロジックをテーブルの拡張定義として置ければ理想的ですが、実装基盤がそれを許すようでなければ無理です。だから実装基盤のあり方に関する議論はものすごく重要なんですが、ほとんど取り上げられませんね。なにしろ開発者が少なすぎますからね(^^;

投稿: わたなべ | 2017.11.23 08:35

返信、ありがとうございます!

>実装基盤のあり方に関する議論はものすごく重要

確かに、そもそも実装基盤が対応していなければ、工夫のしようが無いですからね。。
ちなみに、X-TEA Driverでは業務ロジックを、

アプリケーション
→サブシステム名
→テーブル一覧
→テーブル名

のスクリプトタブに記載するものでしょうか?
その辺のX-TEA Driverの解説を扱った記事がありましたら、教えて頂きたいです。

投稿: くまきち | 2017.11.23 19:36

言われるように、テーブルの「スクリプト」でjavascriptを使って書くことになります。業務ロジックは一般に複雑で様式化できないため、プログラミング言語で扱われざるを得ません。ただし業務ロジックはJavaのような大げさな言語ではなく、軽量言語を使って端正にまとめられるならそれがベストです。

そこではオブジェクト指向など無用の長物で、オブジェクト指向は「実装基盤」のようなはるかに複雑なソフトウエアを開発するための道具だと私は捉えています。私はそのためにこの10年で10万ステップのJavaを書いてきましたが、じつに優れた言語だとしみじみ思います。

なお、スクリプトの書き方についてはX-TEA Editor上でF1を押すと出てくるヘルプにいろいろと書いてあります。

投稿: わたなべ | 2017.11.24 09:22

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 業務ロジックをアプリに置いてはいけない:

« 機能タイプ&テーブルポジションで効率アップ | トップページ | テーブル操作と業務ロジックの連動制御 »