DMNとは
DMNとは、Decision Model and Notationのことで、OMG (Object Management Group)により制定された、ビジネス上の意思決定とビジネスルールを正確に指定するためのモデリング言語および表記法です。https://www.omg.org/dmn/
OMGというと、UMLとかBPMNとかを制定している団体ですね。
（そういえば、はるか昔に、UMLの認定試験というのを受けたことがあったな。。。あの認定資格は今も生きているのだろうか?）
DMNは2015年に1.0がでて、まだ歴史はそれほど長くないのですが、システム開発において、業務要件を整理していくのに、とても便利なツールなので、今日はその中のDRDについて、概要をまとめてみました。
DMNの基本
OMGのサイトによると、2020/3に、バージョン1.3が制定されています。仕様のすべては、PDFでダウンロード出来ます。
https://www.omg.org/spec/DMN/1.3/PDF
左側が、BPMNで定義された、業務プロセスモデル。この例でいうと、その中の「Decide routing」という何らかの意思決定が行われるタスクの意思決定ロジックをより詳細にモデル化するのが、右側のDMNという位置付け。
DMNにも２段階があり、Decision Requirements Level → Decision Logic Level と詳細化していきます。
Decision Requirements Levelで使用するのが、DRD（Decision Requirements Diagram）です。
DRD(Decision Requirements Diagram)
たとえば、こんな感じ。
要素は数種類しかなく、すぐに覚えられます。
この中で、デシジョンとインプットデータと実線矢印だけを使う、でも、割と十分だったりします。
「ビジネス知識モデル」が、実際の意思決定ルールにあたります。１つのデシジョンに１つ以上のビジネス知識モデルがひも付きます。
知識ソースは、そのルールの拠り所となる文献などを表します。書かなくてもよいですが、書いておくことで元のルールが変わった際に、どこを変えればよいかのひも付きがすぐにわかるようになるので、DRDを設計書として残す場合には、有用かなと思います。
最初に書いていくのは、一番上の「経費算出」デシジョンです。このデシジョンが最終アウトプットになります。この例では１つですが、複数あることもあります。
そして、そのアウトプットを決めるのに必要な、各種デシジョンとデータとを下にさかのぼりながら書いていきます。
あるデシジョンのアウトプットが、次のデシジョンのインプットになる、という場合に、デシジョンとデシジョンが矢印（→）で結ばれます。
この矢印（→）は、処理フローではなく、デシジョンの前後関係を表すものであることに、注意してください。
交通費計算のデシジョンから、経費算出のデシジョンに矢印が伸びているのは、交通費計算のアウトプットが、経費算出のインプットになるということを表します。
そして、「出張費精算」という太い黒線が、デシジョンサービス境界を表します。
デシジョンサービスは、再利用可能なロジックとして、１つ以上のデシジョンを持つものとして定義します。
DMNでは実装方法についての指定はしませんが、Webサービスとして、呼び出されるような実装にするのがよいですね。
デシジョンサービスの実装には、ルールエンジンを使うのが、最も適しています。
デシジョンサービス境界は、DRDを書き進めていった最後の方に決定します。
デシジョンサービス境界の例
https://www.omg.org/spec/DMN/1.3/PDFより
デシジョンサービスの境界をどこに設けるべきか、については、ステートレスなサービスとして実装が可能かどうか、で判断するとよいと思います。
途中で人による判断が必要になる場合や、DBにアクセスして新たなインプットデータを取得する必要がある場合などは、そこがデシジョンサービスの切れ目になります。
インプットデータや、ビジネス知識モデルは、デシジョンサービスの外にあります。
ビジネス知識モデルは、外から差し込むというイメージですね。
このあたりも、ルールエンジンで実装してルール定義を外から差し込むというイメージに親しいものがあります。
DRDはとても便利だと思うのですが、アウトプットとして出てくるものは明確に書かない（書けない）ので、
私は勝手にこれに、アウトプットデータをインプットデータと同様に書き込んだりしてます。
そうすると、デシジョンサービスのI/F定義がわかりやすくなります。
このように、業務ルールを決めている人、または管理している人が、どのように意思決定をしているか、という視点で、モデリングをしていきます。
決して、「現行システムでどのように処理しているか」というシステム目線で書くものではないし、書くべきではありません。
デシジョンテーブル
DRDである程度整理が出来たら、各デシジョンを詳細化していきます。
DRDの１つのデシジョンは、１つ以上のデシジョンテーブル（デシジョンテーブル形式以外で書く場合もある）で実装されます。
DMNでは、デシジョンテーブルの記述についても、規約が設けられています。
https://www.omg.org/spec/DMN/1.3/PDFより
また、セル内の条件式の記述形式についても、FEELという規約が設けられています。(FEEL(friendly enough expression language))
これらに則ってルールを記述すると、DMNランタイムを備えたツールで、記述したDMNを実際に動かすことが可能になります。
とは言うものの、実際の実装現場では、DMNランタイムではなく、各種ルールエンジン製品を使った実装のほうが現実的です。
DRDでデシジョンサービスの定義がある程度固まったら、インプットデータ、アウトプットデータのデータモデルを定義し、各デシジョンをルールエンジン製品の実装方法に従って、実装するというのが一般的な実装の流れかと思います。
おすすめのルールエンジン
Drools
https://www.drools.org/
いわずとしれた、オープンソースのルールエンジン。
Red Hat Decision Manager
https://www.redhat.com/ja/technologies/jboss-middleware/decision-manager
Droolsの商用版。
DMN記述ツール
上記のルールエンジンにも、DMNエディターが付属しています。
また、VSCodeのエクステンションにも、DMNエディターがあります。
https://marketplace.visualstudio.com/items?itemName=redhat.vscode-extension-red-hat-business-automation-bundle
なお、こちらからもDMNを試して見ることが可能です。（若干UIがバグるところあり）
↓https://kiegroup.github.io/kogito-online/#/
