ドメインロジックとSQL

トランザクションスクリプト

トランザクションスクリプトは、P of EAAでリクエストを処理する手続き型スタイルに私が付けたパターン名です。この場合、プロシージャは必要なすべてのデータを読み取り、メモリ内で選択と操作を行って、必要な月を特定します。

def cuillen_months name
  customerID = find_customerID_named(name)
  result = []
  find_orders(customerID).each do |row| 
    result << row['date'].month if cuillen?(row['orderID'])
  end
  return result.uniq
end

def cuillen? orderID
  talisker_total = 0.dollars
  find_line_items_for_orderID(orderID).each do |row|
    talisker_total += row['cost'].dollars if 'Talisker' == row['product']
  end
  return (talisker_total > 5000.dollars)
end

cuillen_monthsメソッドとcuillen？メソッドの2つのメソッドには、ドメインロジックが含まれています。これらは、データベースにクエリを発行する多くの「ファインダー」メソッドを使用します。

def find_customerID_named name
  sql = 'SELECT * from customers where name = ?'
  return $dbh.select_one(sql, name)['customerID']
end

def find_orders customerID
  result = []
  sql = 'SELECT * FROM orders WHERE customerID = ?'
  $dbh.execute(sql, customerID) do |sth|
    result = sth.collect{|row| row.dup}
  end
  return result
end

def find_line_items_for_orderID orderID
  result = []
  sql = 'SELECT * FROM lineItems l WHERE orderID = ?'
  $dbh.execute(sql, orderID) do |sth|
    result = sth.collect{|row| row.dup}
  end
  return result
end

多くの点で、これは非常に単純なアプローチであり、特にSQLの使用において非常に非効率的です。データをプルバックするために複数のクエリが必要になります（2 + N、ここでNは注文の数）。現時点ではあまり心配しないでください。後で改善方法について説明します。代わりに、アプローチの本質に集中してください。考慮する必要があるすべてのデータを読み取り、ループして必要なものを選択します。

（余談ですが、上記のドメインロジックは読みやすくするためにそのように行われています。しかし、それは私が慣用的なRubyだと感じているものではありません。Rubyの強力なブロックとコレクションメソッドをもっと活用する以下のメソッドの方が好きです。このコードは多くの人には奇妙に見えるでしょうが、Smalltalkerはそれを楽しむはずです。）

def cuillen_months2 name
  customerID = find_customerID_named(name)
  qualifying_orders = find_orders(customerID).select {|row| cuillen?(row['orderID'])}
  return (qualifying_orders.collect {|row| row['date'].month}).uniq
end

ドメインモデル

2番目の開始点として、古典的なオブジェクト指向ドメインモデルを検討します。この場合、インメモリオブジェクトを作成します。この場合、データベーステーブルをミラーリングします（実際のシステムでは、通常は正確なミラーではありません）。一連のファインダーオブジェクトがデータベースからこれらのオブジェクトをロードします。オブジェクトがメモリに読み込まれたら、それらに対してロジックを実行します。

ファインダーから始めます。これらはデータベースに対してクエリを発行し、オブジェクトを作成します。

class CustomerMapper
  def find name
    result = nil
    sql = 'SELECT * FROM customers WHERE name = ?'
    return load($dbh.select_one(sql, name)) 
  end
  def load row
    result = Customer.new(row['customerID'], row['NAME'])
    result.orders = OrderMapper.new.find_for_customer result
    return result
  end
end

class OrderMapper
  def find_for_customer aCustomer
    result = []
    sql = "SELECT * FROM orders WHERE customerID = ?" 
    $dbh.select_all(sql, aCustomer.db_id) {|row| result << load(row)}
    load_line_items result
    return result
  end
  def load row
    result = Order.new(row['orderID'], row['date'])
    return result  
  end
  def load_line_items orders
    #Cannot load with load(row) as connection gets busy
    orders.each do
      |anOrder| anOrder.line_items = LineItemMapper.new.find_for_order anOrder
    end
  end
end

class LineItemMapper
  def find_for_order order
    result = []
    sql = "select * from lineItems where orderID = ?"
    $dbh.select_all(sql, order.db_id) {|row| result << load(row)}
    return result
  end
  def load row
    return LineItem.new(row['lineNumber'], row['product'], row['cost'].to_i.dollars)
  end
end

これらのloadメソッドは、次のクラスをロードします

class Customer...
  attr_accessor :name, :db_id, :orders
  def initialize db_id, name
    @db_id, @name = db_id, name
  end

class Order...
  attr_accessor :date, :db_id, :line_items
  def initialize (id, date)
    @db_id, @date, @line_items = id, date, []
  end

class LineItem...
  attr_reader :line_number, :product, :cost
  def initialize line_number, product, cost
    @line_number, @product, @cost = line_number, product, cost
  end

cuillen月を決定するロジックは、いくつかのメソッドで記述できます。

 
class Customer...
  def cuillenMonths
    result = []
    orders.each do |o|
      result << o.date.month if o.cuillen?
    end
    return result.uniq
  end

class Order...
  def cuillen?
    discountableAmount = 0.dollars
    line_items.each do |line| 
      discountableAmount += line.cost if 'Talisker' == line.product
    end
    return discountableAmount > 5000.dollars
  end

このソリューションは、トランザクションスクリプトバージョンよりも長くなっています。ただし、オブジェクトをロードするロジックと実際のドメインロジックがより分離されていることを指摘する価値があります。このドメインオブジェクトセットに対する他の処理はすべて、同じロードロジックを使用します。したがって、多くの異なるドメインロジックを実行している場合、ロードロジックの労力はすべてのドメインロジックにわたって償却されるため、問題が少なくなります。そのコストは、メタデータマッピングなどの手法によってさらに削減できます。

ここでも、多くのSQLクエリがあります（2 +注文数）。

SQLでのロジック

最初の2つの両方で、データベースは多かれ少なかれストレージメカニズムとして使用されます。私たちが行ったのは、特定のテーブルから非常に単純なフィルタリングを使用してすべてのレコードを要求することだけです。SQLは非常に強力なクエリ言語であり、これらの例で使用されている単純なフィルタリング以上のことができます。

SQLを最大限に活用することで、すべての作業をSQLで行うことができます

def discount_months customerID
  sql = <<-END_SQL
  SELECT DISTINCT MONTH(o.date) AS month
    FROM lineItems l 
      INNER JOIN orders o ON l.orderID = o.orderID 
      INNER JOIN customers c ON o.customerID = c.customerID
    WHERE (c.name = ?) AND (l.product = 'Talisker')
    GROUP BY o.orderID, o.date, c.NAME
    HAVING (SUM(l.cost) > 5000)
  END_SQL
  result = []
  $dbh.select_all(sql, customerID) {|row| result << row['month']}
  return result
end

これを複雑なクエリと呼んでいますが、以前の例の単純なselect句とwhere句のクエリと比較してのみ複雑です。SQLクエリはこれよりもはるかに複雑になる可能性がありますが、多くのアプリケーション開発者は、これほど最小限に複雑なクエリでさえ敬遠するでしょう。

理解容易性

SQLはしばしば特別な言語と見なされ、アプリケーション開発者が扱う必要のないものとされています。実際、多くのデータベースフレームワークは、それらを使用することでSQLを扱う必要がなくなると主張しています。私はいつも適度に複雑なSQLにかなり慣れているので、これはやや奇妙な議論だと感じてきました。しかし、多くの開発者は、SQLを従来の言語よりも扱いにくいと感じており、多くのSQLイディオムはSQLの専門家でなければ理解するのが難しいです。

良いテストは、3つのソリューションを見て、どれがドメインロジックを理解しやすく、したがって変更しやすいかを確認することです。私は、わずか数個のメソッドで構成されるドメインモデルバージョンが最も理解しやすいと思います。これは、データアクセスが分離されていることが大きな理由です。次に、インメモリトランザクションスクリプトよりもSQLバージョンを好みます。しかし、他の読者は別の好みを持っていると確信しています。

チームの大部分がSQLに慣れていない場合、それはドメインロジックをSQLから遠ざける理由となります。（少なくとも中級レベルまで、より多くの人々にSQLのトレーニングを検討する理由にもなります。）これは、チームの構成を考慮しなければならない状況の1つです。人々はアーキテクチャの決定に影響を与えます。

重複の回避

私が遭遇した最もシンプルでありながら強力な設計原則の1つは、重複を避けることです。これは、プラグマティックプログラマーによってDRY（Don't Repeat Yourself）原則として定式化されています。（プラグマティックプログラマー）

この場合のDRY原則について考えるために、このアプリケーションの別の要件を考えてみましょう。特定の月の顧客の注文リストで、注文ID、日付、総費用、およびこの注文がCuillenプランの対象となる注文かどうかを表示します。これらはすべて総費用でソートされます。

このクエリを処理するためにドメインオブジェクトアプローチを使用するには、総費用を計算するメソッドを注文に追加する必要があります。

class Order...
  def total_cost
    result = 0.dollars
    line_items.each {|line| result += line.cost}
    return result
  end
 

それができれば、注文リストを簡単に印刷できます。

class Customer
  def order_list month
    result = ''
    selected_orders = orders.select {|o| month == o.date.month}
    selected_orders.sort! {|o1, o2| o2.total_cost <=> o1.total_cost}
    selected_orders.each do |o|
      result << sprintf("%10d %20s %10s %3s\n",  
	o.db_id, o.date, o.total_cost, o.discount?)
    end
    return result
  end
 

単一のSQLステートメントを使用して同じクエリを定義するには、相関サブクエリが必要です。これは一部の人々にとって困難です。

 def order_list customerName, month
  sql = <<-END_SQL
     SELECT o.orderID, o.date, sum(li.cost) as totalCost,
            CASE WHEN
              (SELECT SUM(li.cost)
                 FROM lineitems li
                 WHERE li.product = 'Talisker' 
                   AND o.orderID = li.orderID) > 5000 
               THEN 'Y' 
               ELSE 'N' 
            END AS isCuillen
       FROM  dbo.CUSTOMERS c 
         INNER JOIN dbo.orders o ON c.customerID = o.customerID 
         INNER JOIN lineItems li ON o.orderID = li.orderID
       WHERE (c.name = ?) 
         AND (MONTH(o.date) = ?) 
       GROUP by o.orderID, o.date
       ORDER BY totalCost desc 
  END_SQL
  result = ""
  $dbh.select_all(sql, customerName, month) do |row|
      result << sprintf("%10d %20s %10s %3s\n", 
			row['orderID'], 
			row['date'], 
			row['totalCost'],
			row['isCuillen'])
  end
  return result
end

どちらの方が理解しやすいかについては、人によって意見が異なります。しかし、ここで私が考えている問題は、重複の問題です。このクエリは、月だけを提供する元のクエリのロジックを複製しています。ドメインオブジェクトアプローチにはこの重複がありません。cuillenプランの定義を変更したい場合は、`cuillen?` の定義を変更するだけで、すべての使用箇所が更新されます。

さて、重複の問題でSQLを批判するのはフェアではありません。なぜなら、リッチSQLアプローチでも重複を避けることができるからです。データベース愛好家が指摘したくてたまらないであろうコツは、ビューを使用することです。

簡潔にするためにOrders2と呼ばれるビューを、次のクエリに基づいて定義できます。

  SELECT  TOP 100 PERCENT 
               o.orderID, c.name, c.customerID, o.date, 
               SUM(li.cost) AS totalCost, 
               CASE WHEN
                     (SELECT SUM(li2.cost)
                        FROM lineitems li2
                        WHERE li2.product = 'Talisker' 
                          AND o.orderID = li2.orderID) > 5000 
                  THEN 'Y' 
                  ELSE 'N' 
               END AS isCuillen
   FROM dbo.orders o 
     INNER JOIN dbo.lineItems li ON o.orderID = li.orderID 
     INNER JOIN dbo.CUSTOMERS c ON o.customerID = c.customerID
   GROUP BY o.orderID, c.name, c.customerID, o.date
   ORDER BY totalCost DESC

これで、このビューを使用して、月を取得し、注文リストを作成できます。

def cuillen_months_view customerID
  sql = "SELECT DISTINCT month(date) FROM orders2 WHERE name = ? AND isCuillen = 'Y'"
  result = []
  $dbh.select_all(sql, customerID) {|row| result << row[0]}
  return result
end

def order_list_from_view customerName, month
  result = ''
  sql = "SELECT * FROM Orders2 WHERE name = ? AND month(date) = ?"
  $dbh.select_all(SQL, customerName, month) do |row|
      result << sprintf("%10d %10s %10s\n", 
			row['orderID'], 
			row['date'], 
			row['isCuillen'])
  end
  return result
end

ビューは両方のクエリを簡素化し、主要なビジネスロジックを1か所にまとめます。

重複を避けるためにこのようにビューを使用することについて、人々が議論することはめったにないように思われます。私が見たSQLに関する書籍では、この種のことを議論しているようには見えません。一部の環境では、データベース開発者とアプリケーション開発者の組織的および文化的な分裂のために、これは困難です。多くの場合、アプリケーション開発者はビューを定義することを許可されておらず、データベース開発者は、アプリケーション開発者がこのようなビューを作成することを思いとどまらせるボトルネックとなっています。DBAは、単一のアプリケーションによってのみ必要とされるビューの構築を拒否することさえあります。しかし、私の意見では、SQLは他の何と同じくらい設計に注意を払うに値します。

カプセル化

カプセル化は、オブジェクト指向設計のよく知られた原則であり、一般的なソフトウェア設計にもよく当てはまると思います。基本的に、プログラムは、データ構造をプロシージャ呼び出しのインターフェースの背後に隠すモジュールに分割する必要があるとされています。この目的は、システム全体に大きな波及効果を引き起こすことなく、基盤となるデータ構造を変更できるようにすることです。

この場合、問題はデータベースをどのようにカプセル化できるかということです。優れたカプセル化スキームにより、アプリケーション全体で面倒な編集を行うことなく、データベーススキーマを変更できます。

エンタープライズアプリケーションの場合、一般的なカプセル化の形式はレイヤリングです。ここでは、ドメインロジックをデータソースロジックから分離するように努めます。そうすれば、データベース設計を変更しても、ビジネスロジックで動作するコードは影響を受けません。

ドメインモデルバージョンは、この種の カプセル化の良い例です。ビジネスロジックはインメモリオブジェクトでのみ機能します。データがそこにどのように到達するかは完全に分離されています。トランザクションスクリプトロジックは、findメソッドを通じてある程度のデータベースカプセル化を行いますが、データベース構造は返される結果セットを通じてより明らかにされます。

アプリケーションの世界では、プロシージャとオブジェクトのAPIを通じてカプセル化を実現します。SQLに相当するものはビューを使用することです。テーブルを変更する場合、古いテーブルをサポートするビューを作成できます。ここでの最大の問題は更新であり、ビューでは正しく実行できないことがよくあります。これが、多くのショップがすべてのDMLをストアドプロシージャでラップする理由です。

カプセル化は、ビューの変更をサポートするだけではありません。データへのアクセスとビジネスロジックの定義の違いについてもです。SQLでは、2つが簡単にぼやける可能性がありますが、それでも何らかの形式の分離を行うことができます。

例として、クエリの重複を避けるために上記で定義したビューを考えてみましょう。そのビューは、データソースとビジネスロジックの分離の線に沿って分割できる単一のビューです。データソースビューは次のようになります。

   SELECT o.orderID, o.date, c.customerID, c.name, 
          SUM(li.cost) AS total_cost,
          (SELECT SUM(li2.cost)
             FROM lineitems li2
             WHERE li2.product = 'Talisker' AND o.orderID =li2.orderID
           ) AS taliskerCost
      FROM  dbo.CUSTOMERS c 
        INNER JOIN dbo.orders o ON c.customerID = o.customerID 
        INNER JOIN dbo.lineItems li ON li.orderID = o.orderID
      GROUP BY o.orderID, o.date, c.customerID, c.name

次に、このビューを、ドメインロジックに焦点を当てた他のビューで使用できます。Cuillenの適格性を示すものがここにあります。

      SELECT orderID, date, customerID, name, total_cost, 
             CASE WHEN taliskerCost > 5000 THEN 'Y' ELSE 'N' END AS isCuillen
        FROM dbo.OrdersTal

この種の考え方は、ドメインモデルにデータをロードする場合にも適用できます。以前、ドメインモデルのパフォーマンスの問題は、cuillen月のクエリ全体を取得し、それを単一のSQLクエリに置き換えることで対処できることについて説明しました。別の方法は、上記のデータソースビューを使用することです。これにより、ドメインロジックをドメインモデルに保持しながら、より高いパフォーマンスを維持できます。明細項目は、遅延ロードを使用して必要な場合にのみロードされますが、適切な概要情報はビューを介して取得できます。

ビュー、または実際にはストアドプロシージャを使用すると、ある程度までしかカプセル化できません。多くのエンタープライズアプリケーションでは、データは複数のソース、つまり複数のリレーショナルデータベースだけでなく、レガシーシステム、他のアプリケーション、およびファイルからもたらされます。実際、XMLの成長により、ネットワーク経由で共有されるフラットファイルからのデータが増える可能性があります。この場合、完全なカプセル化は、実際にはアプリケーションコード内のレイヤーによってのみ実行できます。これは、ドメインロジックもメモリに配置する必要があることをさらに意味します。

データベースの移植性

多くの開発者が複雑なSQLを敬遠する理由の1つは、データベースの移植性の問題です。結局のところ、SQLの約束は、多数のデータベースプラットフォームで同じ標準SQLを使用できるため、データベースベンダーを簡単に変更できることです。

実際には、それは常に少しばかりのごまかしでした。実際には、SQLはほとんど標準ですが、あらゆる種類の小さな落とし穴があります。ただし、注意すれば、データベースサーバー間で移動するのがそれほど苦痛ではないSQLを作成できます。しかし、これを行うと、多くの機能が失われます。

データベースの移植性に関する決定は、最終的にはプロジェクト固有のものとなります。最近は、以前ほど問題ではなくなっています。データベース市場は揺らいでいるため、ほとんどの場所は3つの主要な陣営のいずれかに分類されます。企業はしばしば、自分が所属する陣営に強いコミットメントを持っています。この種の投資のためにデータベースを変更する可能性が非常に低いと考えると、データベースが提供する特別な機能を活用し始めるのも良いでしょう。

複数のデータベースにインストールしてインターフェースできる製品を提供する人々など、一部の人々は依然として移植性を必要としています。この場合、安全に使用できるSQLの部分に非常に注意する必要があるため、ロジックをSQLに配置することに対するより強力な議論があります。

テスト容易性

テスト容易性は、設計に関する議論で十分に取り上げられてこなかったトピックです。テスト駆動開発（TDD）の利点の1つは、テスト容易性が設計の重要な部分であるという概念を再燃させたことです。

SQLの一般的な慣行はテストしないことのようです。実際、重要なビューやストアドプロシージャが構成管理ツールに保持されていないことさえ珍しくありません。それでも、テスト可能なSQLを持つことは確かに可能です。一般的なxunitファミリには、データベース環境内でテストに使用できる多くのツールがあります。テストデータベースなどの進化型データベース技術を使用して、TDDプログラマーが享受しているものと非常によく似たテスト可能な環境を提供できます。

違いを生む可能性のある主な領域はパフォーマンスです。直接SQLは本番環境では高速であることが多いですが、実際のデータベース接続をサービスタブに置き換えることができるようにデータベースインターフェースが設計されている場合、メモリ内のビジネスロジックでテストを実行する方がはるかに高速になる可能性があります。