S_a_k_Uの日記みたいなDB

~サクゥーと呼ばないで~

SOAとアーキテクチャと依存関係と非機能要件

やっぱ非機能要件で引っかかるね。
今までは開発側視点だったけど、今回はお客さん内部での利用者側視点での標準化とかアーキテクチャ設計みたいな感じなの。


今までは、パッケージ依存とパッケージ間連携で、非機能要件(レスポンス等)からある程度の疎結合をあきらめてた。RDB使うのにJOINなしはないでしょwみたいな。
テーブルの持ち主(パッケージ=要件)と、参照方向(JOINする側/される側)を明確にすることで、UML上のパッケージの依存関係とER図上のテーブルの依存関係を同意にすることを基本方針としてた。そういう意識のおかげで、以前よりテーブル設計もキレイにできてるような気がする。
その時メカニズムとして、RDBMSをデータストアとしての外部システムみたいに捉えて、アプリケーション側にSQLを書くのではなく、VIEWやストアドとかで解決するという案も考えてみたけど、結局それは却下してみたり。


今回はSOAというのが基本にあるので、サービス間でも同じような課題があるみたい。
開発側視点ではないので、上記のような方向へ安易にw持っていけないようにも思うし、途中から参画してて経緯とかがハッキリ把握できてないので、まだまだ議論を深めていってみないと、どうすべきかってのがまだまだ見えない感じ。