業務アプリとDOA

work

結局 「データの出し入れ」を行うだけの業務アプリケーションには、オブジェクト指向分析/設計はあわない。『データ指向アプローチ(DOA)』でドメインモデルを設計したほうが、データベースとの相性は良くなる。オブジェクト指向アプローチは、「振る舞い」を重視するサービス指向アプリケーションに向いている。

同意です。
「業務アプリ」の中の「業務ロジック」部分をOOAで進めるのは危険だと思ってます。
GUIやフレームワーク部分はOOA・OOPの利点を活かせると思います。
まだ自分は経験が浅いので、「あわない」とは断言できませんが、教科書どおりのオブジェクト指向分析で業務ロジック作ったらすっごいムダでパフォーマンスでないものができあがってしまうと思います。（実際、つくりかけてしまった・・）業務アプリでのロジックはほとんどデータのフィルタリングをするぐらいなのに。
業務に精通＆OOA熟練の人がいれば、うまくいくのかもしれません。
でも現実にはそういう人をプロジェクトに迎えるのはなかなか難しいことです。


「性能より移植性を重視するべきだ」の原則（古典？）は理解できますが、業務アプリが支援する業務は異常なスピードで変わります。それを見越して汎用性を持たせるとモンスターみたいなコードになりがちです。当然、キビキビ動いてくれるはずはありません。
でもビジネスにはスピードが求められるのです。


個人的にはORMもすごい冗長なものだと感じています。設定がめんどくさすぎ・・
与件でdbが決まっているのだからRDBのできることを理解した上で機能性能をフルに活用すべきだと思います。（ビューとかストアドとか一時表とか）
業務ロジックはコロコロ変わります。また、SEは業務の専門家ではないからSEが考えたドメインモデルなんかはお客さんからみたらほとんど意味不明なもので自己満足に陥りがちだと思ってます。


業務ロジックに比べればデータは安定性があるといえます。
また、よく考えられたデータ構造は業務ロジックの複雑さを緩和してくれます。
でも、ここでDOAマンセー！ってわけにもいきません。
だってDOAだけじゃアプリつくれないし。DOAとOOA・OOPの使いどころをちゃんと分けないと。