#pofeaa

さすが渋川さんというエントリ

ドメインロジックとデータソースのレイヤの概念がごちゃごちゃになっていることに気づいたので、用語を列挙した。

ドメインロジックのパターン 説明 トランザクションスクリプト ビジネスロジックを一連の手続きで構築して、その各手順でプレゼンテーションからの1つの要求を処理する ドメインモデル 振る舞いとデータの両方を一体化させたドメインオブジェクトモデル テーブルモジュール データベーステーブルかビューのすべての行に関するビジネスロジックを扱うシングルインスタンス サービスレイヤ サービスのレイヤとアプリケーションの境界を定義する。サービスは利用できる操作セットを設定し、各操作に対するアプリケーションのレスポンスを調整するものである。

ドメインロジックの構造化 パターン シンプルなロジックの場合 トランザクションスクリプト 複雑なロジックの場合 ドメインモデル ロジックの複雑さは普通で、レコードセットに関する優れたツールがある場合 テーブルモジュール

データソースのアーキテクチャ 説明 テーブルデータゲートウェイ データベースに対して「ゲートウェイ」の役割を果たすオブジェクト。1つのインスタンステーブルがテーブル内のすべての行を処理する。 行データゲートウェイ データソース内の1つのレコードに対してゲートウェイの役割を果たすオブジェクト。行ごとに1つのインスタンスが存在する。 アクティブレコード データベーステーブルまたはビューの行をラップし、データベースアクセスをカプセル化してデータにドメインロジックを追加するオブジェクト データマッパー オブジェクト、データベース、およびマッパー自体の独立性を保ちつつ、オブジェクトとデータベース間でデータを移動するマッパーのレイヤ。

特にスクリプト言語の Web フレームワークの比較記事の問題はドメインロジックとテストについて軽視しがちであることだ。

トランザクションスクリプトとドメインモデルを採用するかで複雑さが異なるものを一緒に扱うのは読者の混乱を招くし、ドメインモデルが使えるようにするにはトランザクションスクリプトよりも多くのトレーニング期間が必要になるので、使いやすいだけの判断では、評価はトランザクションスクリプトに偏ってしまう。しかし規模が大きくなるとトランザクションスクリプトの複雑さはドメインモデルを越えてしまい、維持がむずかしくなり、ドメインモデルに移り変わる。

Martin Fower が「ドメインロジックとSQL」というスクリプト言語におけるトランザクションスクリプトからドメインモデルへのリファクタリングのケーススタディを公開している。

開発者側でもドメインロジックのレイヤーとデータソースのレイヤーを混同しがちでドメインロジックとデータソースが一体化した ActiveReord が便利だともてはやされるのが象徴である。ActiveRecord はドメインモデルと列データゲートウェイを一体化させたものであり、テーブルの構造とドメインモデルが一対一に対応しているドメインモデルが小さい場合を前提としている。Clean Code ではデータの特殊形として紹介されている。

P of EAA 本に書いてあることを要約すると次のようになる。