ユーザーが商品を検索する | ドメイン駆動設計ハンズオン

Prev: 管理者が商品を登録する

フィーチャーツリーとユースケース

フィーチャーツリーは以下の通りでした。

• 決済機能
• ユーザー情報変更
• 商品カタログ
  • 商品の検索
  • （実装済み）商品管理
• 注文
  • ショッピングカート
  • 注文受付機能
  • 配送状態確認

ユースケースは以下の通りです。

• （実装済み）管理者が商品を登録する
• ユーザーが商品を検索する
• ユーザーがショッピングカートに商品を追加する
• ユーザーがショッピングカートの中身を確認する

この章では「ユーザーが商品を検索する」ユースケースで、「商品カタログ」グループの「商品の検索」機能を実装していきます。

機能要求を考える

「ユーザーが商品を検索する」ユースケースのデータモデリングをする前に機能要求の詳細を詰める必要があるでしょう。つまり「検索」とは何かです。スクラムならユーザーストーリーとして「ユーザーが商品を検索する」というPBIが作成されスプリントに入る頃には、そのPBIの説明に以下のようなことが書かれていることでしょう。

• 検索条件
  • 商品名：部分一致で検索可能
  • 価格：ユーザーの任意入力で上限下限の両方または片方を指定してその範囲で検索可能
• 画面に出力する内容
  • 20商品ずつ表示
  • 1商品に以下の情報を表示
    • 商品名：30文字を超える場合は31文字以上を…に置き換え（トランケート）
    • 価格

本来なら画面イメージなども用意されレイアウトなども指定されると思いますが、ハンズオンなので省略です。

データモデリングの実施

今回の場合は比較的単純です。商品の一覧を保持するコンテナと商品名と価格を持った商品Entityがあるだけです。

ここで、前回（管理者が商品を登録する）で作ったProduct Aggregateを再利用したら良いのではないかと思えます。しかし、前回作成したProduct Aggregateにはvalid?メソッドが実装されています。valid?メソッドはバリデーションのメソッドであり、今回のユースケース「ユーザーが商品を検索する」は出力するだけなので必要のないメソッドです。また、今回のユースケースでは商品名のトランケートが必要ですが、前回作成したProduct Aggregateにとっては不要な処理です。

このように、似ているからとか再利用できそうだからと使い回すのはよくありません。上記のように保存用の処理と出力用の処理が1つのクラスにあると保存と出力の2つの責務を1つのクラスに持つことになります。これを単一責任の原則に違反した状態といいます。保存と出力というわかりやすい例ですが、双方が出力しかしないのだとしても責務が異なるなら分けるようにしてください。

なお、特に保存と出力のAggregateを分けることをCQRSと呼ぶことがあります。

Aggregateの実装

ではAggregateを実装していきます。今回の場合、商品一覧は配列でも良いのですが、クラスとして実装してみましょう。Module（Package）は商品カタログの商品検索なのでProductCatalog::ProductSearchとします。

# 商品一覧
class ProductCatalog::ProductSearch::ProductList
  attr_reader :products

  # 引数のproductsは以下のような配列
  # [{ name: '商品名A', price: 10000 }, { ... }]
  def initialize(products)
    # 引数の配列の1要素ごとにProductのインスタンスを作成して配列を作る
    @products = products.map do |product|
      ProductCatalog::ProductSearch::Product.new(
        product[:name], product[:price]
      )
    end
  end
end

class ProductCatalog::ProductSearch::Product
  attr_reader :name, :price
  def initialize(name, price)
    @name = name
    @price = price
  end
end

商品名は「30文字を超える場合は31文字以上を…に置き換え（トランケート）」という制限があるのでこれを実装します。

class ProductCatalog::ProductSearch::Product
  # getterからnameを削除
  attr_reader :price
  def initialize(name, price)
    @name = name
    @price = price
  end

  # getterの代わりにトランケートした文字列を返すメソッドを実装
  def name
    return @name if 30 < @name.length

    @name[0..29] + '…'
  end
end

Repositoryの実装

今回は前回と比べて多少複雑なRepositoryの実装になります。検索処理とインピーダンスミスマッチの解消でフレームワークの機能を多用するのが理由です。

検索条件は以下の通りでした。

• 検索条件
  • 商品名：部分一致で検索可能
  • 価格：ユーザーの任意入力で上限下限の両方または片方を指定してその範囲で検索可能

class ProductCatalog::ProductSearch::ProductListRepository
  def search(name: '', from_price: nil, to_price: nil, page: nil)
    products = Product
    products = base.where('name like ?', "%#{name}%") if name.present?
    products = base.where('? <= price', from_price) if from_price.present?
    products = base.where('price <= ?', to_price) if to_price.present?

    products = products.page(page).per(20)
    # ActiveRecordの配列から以下の形式のhashの配列に変換している
    # [{ name: '商品名A', price: 10000 }, { ... }]
    product_hash_list = products.select(:id, :name)
                                .map(&:attributes)
                                .map(&:symbolize_keys)

    ProductCatalog::ProductSearch::ProductList.new(product_hash_list)
  end
end

# AggregateのインスタンスとKaminariのインスタンスの両方を返す例
def search(...)
  ....
  return [ProductList.new(...), products.page(page).per(20)]
end

# インスタンス変数に入れて別途取得できるようにする例
attr_reader :products_pagination

def search(...)
  ...
  @products_pagination = products.page(page).per(20)
  ...
end

ApplicationServiceの実装

では最後に「ユーザーが商品を検索する」ユースケースに対応するApplicationServiceを実装していきます。といっても、Repositoryを呼び出して、生成したProductListを返すだけです。

# ユーザーが商品を検索する
class UserSearchProduct
  def perform(name: '', from_price: nil, to_price: nil, page: nil)
    ProductCatalog::ProductSearch::ProductListRepository.new.search(
      name: name, from_price: from_price, to_price: to_price, page: page
    )
  end
end

ここで、いくつか選択肢が出てきます。上記はそのままDomainModelをApplicationServiceの呼び出し元（Controllerやバッチ、rails consoleなど）に返してしまっています。これをレイヤまたぎとして嫌うなら、DTOを定義したりJSON的なHashと配列のデータにして受け渡すということもできます。できますが、おそらくそれはオーバーエンジニアリングです。そうすることにどういうメリットがあるのか考えてください。そして、そのメリットを本当に享受できるのかも考えてください。その上で、バケツリレーするためだけのコードが増えること、それに伴う実装コストの増加と可読性の低下などがペイするだけのメリットが享受できるのかを考えてください。

Next: 管理者がセール情報を登録する