ルール駆動開発
全アプリ開発者に伝えたい、レガシーコードから脱却するための具体的な手法、“ルール駆動開発”
スパゲティ化・ブラックボックス化したレガシーなアプリケーション。
このまま塩漬けにしてよいわけもないが、はたしてどこから手を付ければよいか、どんな手法でモダナイズしていけばよいのか。
その一つの答えとして、「ルール駆動開発」があります。
複雑に絡み合った既存システムをどのように解きほぐしていけばよいのか。
ルールエンジンを使った開発を数多く手掛けてきた中で、レッドハット社内で培われたノウハウと、見えてきたベストプラクティスの一部を紹介します。
発表者 松田 絵里奈[レッドハット]
本日のいいたいこと「業務ルール＝ビジネスルール＝ビジネスロジック」
業務アプリケーションの設計・開発手法
- クラウドネイティブアーキテクチャ！
- 初めから改修を前提においた開発！
- レガシーアプリの移行時にも有効な手法！
## ルール駆動開発の３つの特徴
- ルールとデータアクセスを完全分割
- 業務目線でルールを整理し、そのまま実装
- イテレーション開発
やりがちなこと 現行プログラムコードの解析 をやめましょう。
⇒そもそも実りある成果があるのか
- 現行コードの解析しても継ぎ足し継ぎ足しの秘伝のタレ様態
- リファクタリングされていない冗長なコード
- 不要なゴミコードの山
- 不要かどうかはコードからは不明
- ゴミの移行に時間とお金をかけることに（60%は使わなかったロジック）
知りたいことは業務要件＝業務ルール
- 業務を知っている人に聞く
- 全部は聞かない、知っているところを確認する
- 業務マニュアルや業務フロー図など、設計からわかることもある
- ヒアリング内容をDMNで整理（Decision Model and Notation） 「判定ロジック」と「データ」
業務用語で書くこと
### DMNから一連の業務ルールをサービスとして切り出す
- ルールのテストがしやすい
- 回収時の影響分性範囲がSE馬原
- DB構成の変更影響を受けにくい
RedHat Decision Manager
ルールエンジン利用時の実装
小さく作ってテストを繰り返しながらルールを育てていく
## ルールのイテレーション開発
新旧一致テストを繰り返し、ルールの精度を高速にあげていくテスト・開発手法
## 正しいルール駆動開発
繰り返しになるが、現行コードは見ないというのは新たな見地だと思う。その代わりに業務ロジックの理解と図式（DMN）を作るのがよいと思われる。
まとめ
- 現行コードからではなく業務ルールからのアプローチで無駄を省く
- 最新業務ルールが常に可視化された状態
- データアクセスとルールを分離し、メンテナンス性向上
- 実験⇒テストで品質向上