« 業務ロジックをアプリに置いてはいけない | トップページ | X-TEA Driverが1.3にリリースアップ »

2016.02.11

テーブル操作と業務ロジックの連動制御

 テーブルに依存する業務ロジック(ビジネスルール)であれば、アプリから独立した「テーブルの拡張定義」として一元的に管理されなければいけない。そしてそれは、アプリによるテーブル操作に応じて暗黙的に呼び出され、アプリと変数域を共有しつつ実行されなければいけない。何のためか。アプリをうすっぺらにして、開発・保守の効率を高めるためだ。前回記事でそのように説明した。

 では、テーブルに依存する業務ロジックであれば、アプリによってテーブル操作がなされたら必ず実行されるべきかというと、じつはそうではない。テーブル操作と業務ロジックを連動させるかどうかは、システム内部のアプリによって選択可能でなければいけない。両者を連動させたいことも、そうでないこともあるからだ。

 このことに関係するのだが、RDBMSによって提供される外部キー制約やカスケードオプションのような「気の利いた機構」を、私はよほどのことがない限り使わない。ユニークキーやインデックスキーの設定程度を除けば、テーブル定義はほとんど「素」のままである。理由は2つある。

 まず、それらの機構では複雑な条件を組み込めないからだ。外部キー制約としては、私の言う「動的参照関係(本ブログでの参考記事)」を扱えない。これなどは、じつにありきたりなデータ要件であるにもかかわらずDDLレベルで組み込めないのが不思議でさえある。カスケードオプションも同様で、起点となるレコードの状態で処理が条件づけされる必要があっても、それを考慮できない。前回記事で取り上げたDefault句も含め、業務ロジックを記述する機構としては中途半端すぎるのである。

 それならば、単純な要件についてはDDLレベルで組み込んで、複雑な条件をともなう要件については別のやり方をとればいい、と思われるかもしれないがそうすべきではない。テーブルに依存している仕様を理解するためにあちこちを調べ回るはめになるからだ。単純だろうが複雑だろうが、テーブルに依存する業務ロジックは1か所にまとめて記述されたほうがいい。わかりやすく言えば、トイレットペーパーの保管場所は「トイレの棚」あたりに固定されるべきであって、あちこちに置かれているとしたらそれは「ゴミ屋敷」である。

 私がRDBMSの「気の利いた機構」を使わない2つ目の理由は、アプリによってはそれらの設定を無視したいからだ。たとえばある種のバッチ処理では、明解なロジックで大量データを一括処理してしまいたいのだが、DDLレベルで組み込まれた制約が邪魔になることがある。制約を避けるようにロジックを組むことが可能であっても、仕様が必要以上に複雑化する。

 けっきょくDDLに組み込める仕様であっても、あえて「業務ロジック」として一元的に定義され、主体的に実行管理されたほうがいいということだ。そんな態勢を実現するのがDSP(ドメイン特化基盤。本ブログでの参考記事)で、業務ロジックとアプリの関係を模式化すると次図のようになる。

▼DSPにおける業務ロジックとアプリの関係
20160211

 テーブルを操作するための手段が2つある点に注目してほしい。テーブル操作に業務ロジックを連動させるもの(a)と、させないもの(b)だ。これらは一見するとDAOクラスのように見えるが、「汎用的なテーブル操作クラス」として基盤によって提供される関数である。つまりテーブル毎のDAOを開発せずに済むということで、これはDB定義がリポジトリとして様式化されているおかげだ。

 では、これらのテーブル操作用関数はどのように使い分けられるのだろう。社内の事務担当者が利用するGUIアプリ(x)や、外部公開されているREST APIのようなアプリ(y)は、業務ロジックと連動する関数(a)を使うことになる。いっぽう、ある種のバッチ処理(z)では、非連動型の関数(b)を使えば便利だろう。図では示されていないが、業務ロジックの内部でもテーブル操作することはあるわけで、そこではおもに非連動型が用いられる。ざっくりいえば、システム外部の「アテにならない主体」を相手にするアプリは、データの整合性を維持するために業務ロジックと連係すべきだ。

 さて前回記事で、この態勢でアプリの開発保守効率が劇的に向上すると説明したが、その他に、特定RDBMSへのロックインを避けられるという利点もある。上述したように、RDBMSの標準的な機構しか用いないのだから当然だ。すでに固有な機構をふんだんに用いて実装されていたとしても、それらの仕様をDSP上で業務ロジックとして定義し直すことで、他のRDBMSに切り替えやすくなる。

 「それでもけっきょくは、特定DSPにロックインされるだけではないのか」と思われるかもしれないが、その逆である。DSP上で業務ロジックをテーブルの拡張定義として一元化することで、それまでは「ゴミ屋敷」のようだったシステムのあり方が整理整頓される。そうなればDSPに限らずどの基盤への移行も楽なのである。DSPには「ドキュメンテーションツール」の側面があるということだ。

 DSPをありきたりな開発合理化手段のひとつと考えていては、「ドメイン特化」であることの意義を見誤る。DSPは「仕様書をまとめるためのツール」であると同時に「仕様書をそのまま動作させるツール」である。複雑膨大なシステムのあり方を「アプリ仕様書」と「業務ロジックを含むリポジトリ」として体系化し直し、ついでにアプリ仕様書をそのまま動作させてしまう――それは開発基盤がドメイン特化しているゆえに可能になったことだ。


★「わんくま同盟/大阪勉強会2016/03/12」で語ります
「ドメイン特化基盤を作ってみた」
ドメインに特化した開発言語(DSL)を用いることで、そのドメイン向けの開発過程が合理化されます。それならば、ドメインに特化した開発基盤(DSP)を用いれば、さらに合理化できそうです。そこで、「業務システム開発」のドメインに向けたDSPを自作しました。出来上がったものは「仕様書を書けばそのまま動作する」開発環境でした。その開発過程と活用事例についてお伝えします。

|

« 業務ロジックをアプリに置いてはいけない | トップページ | X-TEA Driverが1.3にリリースアップ »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: テーブル操作と業務ロジックの連動制御:

« 業務ロジックをアプリに置いてはいけない | トップページ | X-TEA Driverが1.3にリリースアップ »