ユースケースの洗い出し | ドメイン駆動設計ハンズオン

フィーチャーツリーで分類したのだから、ユースケース、つまりApplicationServiceもフィーチャーツリーの通りに分類すれば良いと考えるかもしれません。しかし、実際にはそううまくいきません。

例えば、「ユーザーが注文を確定する」ユースケースで必要になる機能は何でしょうか。注文グループの注文受付機能は当然必要になります。しかし、決済機能も必要になるはずですし、在庫の確保などの機能があるなら、それらの機能も利用することになります。

# ユーザーが注文を確定するユースケース
class UserConfirmOrder
  def perform(params)
    ActiveRecord::Base.transaction do
      # 決済を実行する処理
      # 注文を確定する処理
      # 在庫を確保する処理
    end
  end
end

このように1つのApplicationServiceが複数の機能グループにまたがって実装されることはありえます。教科書的にはこういった状況はイベントソーシングを用いて結果整合性で解決すべきなのかもしれませんが、いずれにせよ1つのユースケースが複数の機能をトリガーしているのだから意味的には同じになります。つまり、フィーチャーツリーによる機能分類をそのままユースケースの分類として使うことは難しいということです。

そのため、私はdomainsディレクトリとusecasesディレクトリを作成し、domainsディレクトリはフィーチャーツリーに基づいたModule（Package）を作成し、usecasesディレクトリにはフィーチャーツリーとは別体系のモジュールで分類したApplicationServiceを格納するというふうにするのが良いと考えています。