【Reflex】 再発見。実はドメインモデルかもしれないReflex

　先日、Reflexはトランザクションスクリプトであると説明した。（トランザクションスクリプトとドメインモデル）
　しかし、ドメイン駆動設計とはという記事を読んであらためて頭を整理してみると、見方によってはトランザクションスクリプトというよりはドメインモデルに近いのではないかと思うようになった。先日どうしてトランザクションスクリプトであると説明したかというと以下のような思い込みがあったからだ。

　 1、ドメイン駆動設計はオブジェクト志向が前提だと考えていたこと。また、それ自身が振る舞いをもつ必要があると考えていたこと。
　２．データと振る舞いが分離されるトランザクションスクリプトとは相反する概念だと思っていたこと
　３、Mashup層のようなフローをもとに手続き的に実行していく概念はないと思っていたこと

　これらの思い込みを排除して素直にドメイン駆動設計を読むとまるでReflex設計そのものを説明しているかのように思えてくるのだ。具体的にそう思えるところを、かいつまんで説明すると次のようになる。ただし、結果的に似ているというだけで、Reflexはドメイン駆動設計を目指すものではないことをお断りしておく。あえて類似点を示すことでReflexをもっとよく理解していただきたいというのが目的である。そもそも私の解釈に間違いがあるかもしれないし、ドメインモデルとは全然違う部分があれば無視していただいて結構である。

＜類似点１　設計思想＞

ドメインモデルを中心にすえた設計思想

　１、ドメインモデルは、ドメイン知識を深めながら反復的（iterative）に深化させていく
　２、ドメインモデルが、開発者とドメイン知識をもつ人（ユーザ、専門家等）との間の共通言語となるようにする
　３、ドメインモデルと実装コードとがきちんと対応付けられるようにする

＜類似点２　設計パターン＞

Ubiquitous Language（ユビキタス言語）パターン

　Reflexはシステム全体のドメインを定義しReflex表現を元にスキーマを作成する。
　
Model-Driven Design（モデル駆動設計）パターン

　スキーマを元にEntity（モデル）を自動生成してプログラムに組み込む。ドメインの修正があればスキーマを修正してモデルを配布しなおす。これによりドメインモデルとプログラムコードとが常にお互いを反映するように保つことができる。

Hands-On Modeler（実践的モデラー）パターン

　プログラマとはスキーマを通じて相互に意見を述べ合うことで、モデリングとプログラミングの好循環を実現できる。モデラはプログラムの内部実装に興味をもたなくてもよい。

モデル駆動設計の基本要素

＜類似点３ ドメイン層の分離＞

Layered Architecture（層状アーキテクチャ）パターン


　UI層 … ユーザとの相互作用の境界となる層
　アプリケーション層 … ドメインオブジェクトを操作することで、ソフトウェアが果たすべき仕事を実現する層
　ドメイン層 … ビジネス上の概念を表現する層
　インフラストラクチャ層 … 上の3層を支える技術的な基盤となる層

ReflexではEntityの集合をドメインとしてUI層やアプリケーション層から分離する。

Smart UI（利口なUI）アンチパターン

　
　UIはReflexではView層がコントロールする。View層ではビジネスロジックやデータアクセスのコードが一緒になることはないが、以下の３つの実装が含まれる。

　１）アトリビュートやバリデーションのための一部プログラムコードが存在する。これは、View層の責務の範囲内である＜参考＞ワンソースマルチビューを実現する

　２）I/Oをもたないビジネスロジックが含まれることがある。これは、View層の責務の範囲外であり別けて設計される。

　３）同じくView層の責務の範囲外であるリソースにアクセスする手段をもつ。

＜類似点４ ソフトウェアによるモデルの表現＞

Entities（エンティティ）パターン


　Reflex表現でスキーマを定義しアイデンティティをもつEntityを管理する。

Value Objects（値オブジェクト）パターン

　これはReflex表現には含まれずアプリケーションで管理することになる

Services（サービス）パターン

　Blogicがこれに該当する。Blogicは、Entityを与えEntityが返るサービスとして定義される。また、I/Oをもたず、View層、Mashup層、Resource層のどのレイヤにも存在することができる。主に、View層では計算ロジック等、Mashup層ではマッシュアップ（Entity⇔Entity変換）、Resource層ではO/Rマッピング（Entity⇔DAO変換）で使用される。

＜類似点５　ドメインオブジェクトのライフサイクル＞

Aggregates（集約）パターン


　ReflexではEntityのルート要素はListの子要素(1..∞)をもつように規定される

Factories（ファクトリ）パターン／Repositories（リポジトリ）パターン


　RESTful設計におけるCRUDが該当する

＜類似点６　しなやかな設計 ― 理解の容易な抽象化＞

Intention-Revealing Interfaces（意図の明白なインタフェース）パターン


　Entityの名詞で統一されることが理解の容易な抽象化につながる。RESTful設計においてインターフェースも明白である。

Side-Effect-Free Functions（副作用の無い関数）パターン


　Blogicは単に引数を加工して結果を返すだけであり副作用の無い関数である。Resourceはアトミックであり副作用はない。（例え内部でエラーが起きてもロールバックされる）Mashupはアトミックなものとそうでないものに分かれる。

Assertions（表明）パターン


　Mashupで副作用が起こる可能性のあるものについては何らかの表明が必要（現在は特に規定していない）

＜考慮点　しなやかな設計 ― 適切な分割＞

以下はそのままReflexにも当てはまると思われるため抜粋をのせる。

Conceptual Contours（概念の輪郭）パターン


　オブジェクトの粒度（Reflexではサービスの粒度）については、モデルのリファクタリングを何度も繰り返すことで概念の輪郭を見つけ出し、オブジェクトの粒度がその輪郭に沿うようにする。これが、ドメインモデリングにおける高凝集のガイドラインである。

Standalone Classes（独立したクラス群）パターン


　人間の頭が一度に考えられる概念の量には、限界がある。ドメインモデルを分かり易くするには、一度に考えなければならない概念の量を絞って、メンタルな負荷の少ないモデルにする必要がある。モデルを構成するクラスのまとまりから、関係のないクラスへの依存関係を極力排除していき、その中だけで独立して理解できる小さな世界を構築しなければならない。これが、ドメインモデリングにおける低結合のガイドラインである。　

Closures of Operations（閉じた操作）パターン


　操作の結果が、その引数と同じ型のオブジェクトを返すような操作（閉じた操作）の導入を検討する。

戦略的デザイン以降で共通点があればまた次の機会に説明したい。

＜追記＞
後で知ったのだがドメインモデル貧血症を起こすらしい。＝＞ドメインモデル貧血症、サービスと振る舞いについて