Business Rule Micro Service
1. 目的
ビジネスルールを簡単に確認したい
- 複雑なビジネスルールを持つシステムを保有しており、そのビジネスルール（仕様）を簡単に確認したい
2. 課題
ドキュメント化が不十分だったり、ルールが複雑過ぎて読み解くことが困難
- システムに実装されているビジネスルールを確認したいが、ビジネスルールが複雑過ぎてドキュメントから読み解くことに多大な労力が掛かってしまう
- あるいは、ドキュメントの整備/更新が追い付いておらず、ドキュメントからでは正しいビジネスルールを導き出せない（実装が「正」になるので現況優先状態になっている）
- そのような状況なので、仕様確認の調査がエンジニアに度々依頼されることになり、エンジニアの調査工数も膨らんでいる
3. 解決策
ビジネスルールをテストする為のマイクロサービスを作成する
- システム内でバリデーションロジックやデータ抽出条件として実装されているビジネスルールを試行する為のマイクロサービス（
Business Rule Micro Service）を作成する
- 具体的にはシステムに
Business Rule Micro Service用のAPIエンドポイントを追加する
- 更に、
Business Rule Micro Serviceに対して任意のパラメータを送信できる管理画面的なものを用意し、実際にシステムに実装されているビジネスルールを確認できるようにする
4. メリット
「生きた」ドキュメントとして機能する
- システムに実装されたロジックを用いて結果を返却する為、常に最新の状態のビジネスルールを確認できるようになる
- 静的なドキュメントと違い、情報が古くなることはない
非エンジニアが自分で仕様を確認できるようになる
- 管理画面を提供することで、ビジネスルールの確認を非エンジニアでも自分で行うことが可能になる
- 毎度エンジニアに調査依頼を出す必要が無くなり、エンジニアに対する割り込みタスクを無くす（あるいは減らす）ことができる
ビジネスルールを記憶する必要が無くなる
- ビジネスルールを記憶/把握することはかなりの努力が必要である
- しかし、その努力は費用対効果が極めて悪い（別の職場どころか別のプロジェクトでさえ役に立たない知識である）
- 人間の記憶/認知リソースは限られており、そのような不毛なタスクで消費するべきではない
-
Business Rule Micro Serviceを一度構築してしまえば、ビジネスルールはシステムに問い合わせれば済むようになり、人間の認知/記憶リソースを消費せずに済む
5. デメリット
コストの増加
- 当然ながら、
Business Rule Micro Serviceの実装コスト/メンテナンスコストは上乗せされる
6. 注意事項
ビジネスルールを独立して実行できるよう凝集性が高い設計をする必要がある
- ビジネスルールは
Business Rule Micro Serviceとして独立して実行できるよう独立した実装になっている必要がある
- 具体的にはバリデーションロジックとして厳密に分離されていなければならない
- ビジネスルールが処理の手続きの中に溶け込んでいるような凝集性の低い実装になっている場合、
Business Rule Micro Serviceと独立させることが困難（あるいは不可能）になる場合もある
- ビジネスルールの確認の為にシステムに副作用（データ登録や更新）を及ぼしてはいけない
システムやデータに副作用を生じさせないように実装する必要がある
- あくまでもビジネスルールの確認が目的であり、実際に保存されているデータが更新されたり、無意味なデータが登録されてはいけない
ルールエンジンへの移行も検討するべき
- ルールエンジンはまさにこのような判断ロジックを管理する為のアプリケーションなので、ビジネスルールが肥大化/複雑化してきたらルールエンジンへの移行も検討してみるべきである
参考資料