ようやくオブジェクトモデリングの勉強を開始する

オブジェクトモデリングというのはまったく勉強していない領域だ。
何を言っているのか分からなくて嫌いなのだ。
何がこんなに分からないのか、冷静になって考えてみました。

何が理解できないか

私の知ってるオブジェクトモデリングというのは、

  • 問題領域にある名詞を抽出してクラスにする
  • クラス間の多重度を分析する
  • できあがった問題領域の構造(ドメインモデル)に責務を割り振る
  • ドメインモデルを永続化層の上に、極力そのままの形で実装する

みたいな感じで進みます。
こちら世界では、「ドメインモデルをそのまま実装できることが大事」とされています。
児玉公信 UMLモデリングの本質 (日経ITプロフェッショナルBOOKS) P111にこうあります:

一般によく用いられる4層モデルでは、UI層・アプリケーション層・ドメイン層・永続層を設ける。
...
2番目のアプリケーション層には、ユースケースの手続きや処理の手順を示したクラスや
オブジェクトを配置する。
...
3番目のドメイン層には、概念レベルのクラス図に登場するクラスやオブジェクトをそのまま実装する。
4層構造は、概念モデルをドメイン層において忠実に実装するために考えられたアーキテクチャだと
言っても過言ではない。

この、ドメインモデルを実装すると何かいいことがある、という考え方が理解できないわけです。

論理的データ独立の放棄?

問題領域の構造がアプリケーション層に露出すると、全てのユースケースの実装は問題領域の構造を手繰って、必要なデータを取得することになります。
アプリケーションにデータ構造の手繰り方が埋まってしまうので、データ構造の変更に弱いような気がします。
これでは、論理的データ独立のない、RDB以前の世界に戻ってしまうのではないかと不安になります。
永続化層にRDBがあるなら、さらにいやな感じになります。
バックエンドにRDBを持っているのに、その上にドメインモデルを構築して、モデルを手繰って必要なデータを集めてくるアプリケーションを作る、というのは、もう何をやっているのか意味が分からない。
そう感じるわけです。

RDBは被差別民族

現時点の理解では、問題領域の構造が変わった時に

  • 永続層とドメイン層とアプリケーション層を修正するのがオブジェクトモデリングの流儀
  • ドメイン層を作成せず、永続層を修正してアプリケーション層に見せるデータ構造を極力変えたくないのが俺

ということになります。


また、OOの世界ではRDBが被差別民族だと感じています。
個々のユースケースが要求するデータセットをフラットな構造で提供する能力があるのに、使ってもらえない。ドメインモデルのデータを出し入れする道具に成り下がっている。さらに、ドメインモデルを効率的に出し入れできないことに文句を言われる。


オブジェクトモデリングの利点と、あちら側のRDBに対する嫌悪感を理解するために、児玉氏とファウラーの本でモデリングの勉強を始めようと思います。
データモデリングの足腰はできたので、今ならあっちの世界の利点も理解できるはず。