【Reflex】 ドメインモデル貧血症、サービスと振る舞いについて

　自分の頭を整理するために、こちらの記事のように、敢えてReflexをドメインモデルに当てはめて考えてみたものの、案の定、ドメインモデルではない根拠を発見してしまった。Reflexはそのままではドメインモデル貧血症を起こすらしい。

ドメインモデル貧血症

ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな振る舞いしかない、ということに気づくと思います。ドメインのロジックをドメインオブジェクトの中に入れないという設計ルールに従っているのでしょう。その代わり、すべてのドメインロジックを含むサービスオブジェクト群が存在しているのです。こういったサービスはドメインモデルの上位に居座り、データのためだけにドメインモデルを使うのです。

このアンチパターンが根本的に怖いのは、オブジェクト指向設計の基本概念（データと処理を一緒にする）の真逆だということです。ドメインモデル貧血症とは、単なる手続き型設計のことなのです。まさに、私（そしてEric）のようなオブジェクト信望者が、Smalltalkの初期からずーーーーーっと戦ってきたもの、そのものなのです。さらに困ったことに、貧血オブジェクト(Anemic Object) が本物のオブジェクトだと思っているひとがたくさんいます。つまり、オブジェクト指向設計が何たるかをまったく分かっていないということなんです。

　ここで説明されている「貧血症」とは、振る舞いがドメインに欠けている状態であると理解できる。たしかに、オブジェクトは「データ＋振る舞い」であるから、Reflexの振る舞いをもたないResource層に位置するコンポーネント群などはオブジェクトとはいえない。

　しかし、Reflexはそもそもオブジェクトを前提としていないので、データと振る舞いをくっつけることができない。

詳しくは、「MVCモデルは進化する」を参照していただきたいが、Reflexでは「オブジェクト設計をしない」ことがスタート地点になっており「貧血症」というよりは「殻皮類」のようなもので「血」がない生物なのである。なので、「オブジェクト指向設計が何たるかを」全く知らないで開発しても貧血になって倒れたりしない。また、ある意味挑戦的で挑発的な、真の「Domain Model」推進者が知ったら顔を真っ赤にして怒るだろうアンチパターンを平気な顔してやっちゃおうという試みでもあるのだ。

＜MVCモデルは進化するの抜粋＞

そこで、得た結論は、

否定の６．オブジェクト設計をしない


である。正確には、設計クラスのModelをオブジェクトにはしないで、オブジェクトで扱うデータに関心を集めようというもの。Modelとは、モデリングによってできた成果物（※）でありオブジェクトであるから、データとプログラムがくっついている状態。それからプログラムを切り離してデータのみに関心を集めて考える。データだけであればオブジェクトではないのでオブジェクト設計をしないことを意味する。とはいえ、分析クラスまでは設計して論理ビューを作る。論理ビューで定義したサブシステム内であれば、勝手に設計/実装して構わないという感じになる。
（※ Modelの定義は曖昧で様々な説明が存在する。私はこの説明が一番好きだ。）

　また振る舞いがどのように定義されるかについても触れておきたい。振る舞いは、BCEのC(Control)でフローという形で定義されるものである。そして、ControlからEntityが手続き型のように呼ばれる。これはトランザクションスクリプトに近いモデルである。

【IBM sMash】　マッシュアップはサーバでいいんですか。いいんですよ。

それから、sMashで最も重要だと思う点は、サーバサイド Mashupであり、BCEでいうところのControlに照準を当てているということ。Controlは、ビジネスロジックというと語弊があるが、ワークフローのロジック部分といえばしっくりくる。これまでワークフローとWebアプリは別物のようなもので、開発者の多くはイメージしにくいかと思う。また、この記事でも書いたように、ControlはこれまでModelに無理やり詰め込まれていて、あまり意識せずにWebを開発できた。これまで曖昧で意識もされなかったControlであるが、RESTfulな設計を推し進めることで、相対的にくっきりと浮かび上がってきた。resourceは自己完結した情報の集合として静的に扱われる一方、ControlはBoundaryの要求に応じて動的にresourceを編集する機能となる。このようにきれいに分けることで、いわゆる疎結合開発ができるようなる。従来のWeb設計開発では、画面、ビジネスロジック、データベースの３つに依存した密結合開発であったものを、 RESTful設計ではビジネスロジックを外だしにして画面も独立して開発できるようになるのだ。この結果、分業という大きなメリットを享受できるようになった。分業のメリットがいかに大きいかは、この記事で説明したとおりである。

　ちなみに、「サービス」と「振る舞い」は基本的に異なるものとしてReflexでは定義している。どちらもビジネスロジックを記述することには違いないが、振る舞いは「フローという形で定義できるもの」に対して、サービスは「I/Oを持たない揮発性の関数」としている。また、振る舞いはControlのMashup層だけに出現できるが、サービスはBCEのどのレイヤにも出現することができる。（Reflexではサービスはblogic()としている）

【EC開発体験記 -Model-】 2面性をもった掴み所がないオブジェクト

そして、convertに限らず、BlogicはすべてEntityを入れてEntityを返すとしてよさそうである。ただし、BlogicにI/Oを持たせてしまうと外部参照となってしまうため基本的にNGである。ResourceへのアクセスはEntityのCRUDメソッドだけが許されるものとし、さらにBlogicからはそれを呼ぶこともできないとする。EntityのCRUDメソッドを呼べるのはControlからだけだ。
Blogicで可能なことは、Entityを元に計算や変換処理を行って、Entityに詰めなおして返すだけ。なんとも制約の多いものだが、これがカプセル化として働くため、非常に安定したシステムとなる。（後ほど説明するがテストも楽になる）
したがって、Blogicの定義は次のようにする。

１．entity = blogic(entity)
２．Blogicは揮発性である(ステートレスでありデータを保持しない。また、外部リソースへのI/Oはない）

　ドメインモデルでいわれているような、手続き型を否定し、オブジェクトにすることがどれほどのメリットを生み出すかは正直分からない。一方のReflexは実際の私の開発経験から得たノウハウを元にした開発手法である。ドメインモデルの設計に近い部分がありながら敢えてオブジェクトにしない。そうすることでむしろ、オブジェクト設計の呪縛から解放されてシンプルに設計できる。オブジェクト化して「振る舞い」を混合させるのではなく静的なドメインだけに集中して扱う。これがReflexのドメインモデルであり、最も実践的で生産的な手法だと考えているものである。

　最初はこちらの記事のようにReflexをドメインモデルに当てはめても素直に解釈ができたのだが、あらためて考えてみると「振る舞いが記述されていない」との理由でReflexはドメインモデルではないという結論を得た。それはそれでいいと私は思うし、どちらが正しいかなどの議論はするつもりはない。また一見正しそうな結論が出たとしても、実際の開発を元にしない限り往々にして不毛に終わる。これ以上、机上の方法論に時間を費やしたくないのが本音である。