集約の実装について考えてみた

はじめに

DDD の集約の実装について考えたことをまとめます。

題材

料理のレシピ作成を題材としてまとめていきたいと思います。

概要

概要は以下の通りです。

• レシピには材料と作り方がある。
• 材料には食材や調味料などの名前と分量が必要である。
• 材料はメインとなる材料や合わせダレなどのカテゴリごとにグルーピングできるとよい。
• 作り方は具体的な手順を示すものである。

ドメインモデル

上記をドメインモデルで表現するとこのようなイメージです。
各種値の範囲はドメインとして決まっているわけではないですが、システム化する上で決めなければならないことだと思いますので、ドメインエキスパートとすり合わせながら運用に支障をきたさない範囲で決定すると良いのかなと思います。
今回は決定した値の範囲をドメインモデルに補足する形で記載しています。

ユースケース

システムに対するユースケースは以下の通りとし、末端のユースケースごとに編集・保存できるイメージとします。（画面のラフ画があると分かりやすいとは思いますが割愛します。）

本題

それでは本題の集約の実装について考えたことをまとめていきたいと思います。
まずは今回のドメインモデルを単純にクラスに落とし込んでいくとこんな感じになるでしょうか。

この設計だと集約ルートが「レシピ」になりますが、集約の範囲が広すぎると感じます。
ここで一度、集約について私の理解を整理したいと思います。

集約に対する理解

集約で大切な考え方として以下の点が挙げられると考えています。

• 整合性の確保が必要な境界である。
• 集約内部の変更は必ず集約ルートを経由することで集約内を常に整合性が確保された状態にする。
• 集約ルートの単位でデータの取得・永続化を行う。

もし集約ルート以外の変更を許可してしまうと、整合性を確保するための処理が利用側に委ねられてしまい、整合性が崩された状態で永続化されてしまう恐れがあります。集約ルート以外のドメインオブジェクト単体での永続化を許可してしまった場合も同様です。

集約の分割

上記の考え方でいくと、確かにレシピを集約ルートにすれば整合性を確保する境界としては十分だと思いますが、例えば 1 つの材料カテゴリの内容を変更したいだけなのにレシピ全体を DB から取得して、変更後のレシピ全体の情報を DB に保存しなければならず非効率に感じます。

そこで、整合性を確保しつつ効率を高めるために集約を分割していきたいと思います。
例えばこのようにできるでしょうか。

材料と作り方には整合性を確保するための関係性がないため別集約に分けられましたが、材料カテゴリや手順については、10 個以下、100 個以下というルールがあるため、別集約とすることは難しそうです。
ただ、1 つの材料カテゴリの変更に対して全ての材料カテゴリを更新しなければならず非効率であるという問題は残ってしまいます。
やはり材料カテゴリと手順は別集約にしたいところです。
では、最大個数の整合性を確保しつつ別集約にするにはどのようにすれば良いでしょうか？

例えば材料に材料カテゴリ、作り方の個数を管理させるのはどうでしょうか。

以下にこの設計に対する実装例を示していきたいと思います。（kotlin を使用します。）

ドメインオブジェクトの実装

ドメインオブジェクトの実装は以下の通りです。（作り方に関する実装は割愛します。）

// 材料（集約ルート）
class Ingredient private constructor(
        val recipeId: RecipeId,
        val categories: List<IngredientCategoryId>
) {
    companion object {
        private const val CATEGORIES_COUNT_MAX = 10

        // 材料を永続領域から復元する
        fun reconstruct(recipeId: RecipeId, categories: List<IngredientCategoryId>): Ingredient {
            return Ingredient(recipeId, categories)
        }
    }

    // 材料カテゴリを追加する
    fun addCategory(categoryId: IngredientCategoryId): Ingredient {
        return categories.plus(categoryId).let {
            require(it.size <= CATEGORIES_COUNT_MAX) {
                "材料カテゴリは $CATEGORIES_COUNT_MAX 個以下でなければなりません。"
            }
            Ingredient(recipeId, it)
        }
    }

    // 材料カテゴリを並び替える
    fun reorderCategories(orderings: List<Pair<IngredientCategoryId, Int>>): Ingredient {
        val reorderedCategories = // 並び替えの実装は省略
        return Ingredient(recipeId, reorderedCategories)
    }

    // 材料カテゴリを削除する
    fun deleteCategory(categoryId: IngredientCategoryId): Ingredient {
        return Ingredient(recipeId, categories.minus(categoryId))
    }
    
    override fun equals(other: Any?): Boolean { /** 省略（recipeId を同一性として実装する。） **/ }
    override fun hashCode(): Int { /** 省略 **/ }
}

// 材料カテゴリ（集約ルート）
class IngredientCategory private constructor(
        val id: IngredientCategoryId,
        val title: IngredientCategoryTitle,
        val ingredientItems: List<IngredientItem>
) {
    companion object {
        private const val INGREDIENT_ITEM_COUNT_MAX = 100

        // 材料カテゴリを新規作成する
        fun create(title: IngredientCategoryTitle, ingredientItems: List<IngredientItem>): IngredientCategory {
            validateIngredientItems(ingredientItems)
            return IngredientCategory(IngredientCategoryId.newId(), title, ingredientItems)
        }

        // 材料カテゴリを永続領域から復元する
        fun reconstruct(
                id: IngredientCategoryId,
                title: IngredientCategoryTitle,
                ingredientItems: List<IngredientItem>
        ): IngredientCategory {
            return IngredientCategory(id, title, ingredientItems)
        }

        private fun validateIngredientItems(ingredientItems: List<IngredientItem>) {
            require(ingredientItems.size <= INGREDIENT_ITEM_COUNT_MAX) {
                "材料は $INGREDIENT_ITEM_COUNT_MAX 個以下でなければなりません。"
            }
        }
    }

    // 材料カテゴリを変更する
    fun change(title: IngredientCategoryTitle, ingredientItems: List<IngredientItem>): IngredientCategory {
        validateIngredientItems(ingredientItems)
        return IngredientCategory(id, title, ingredientItems)
    }

    override fun equals(other: Any?): Boolean { /** 省略（id を同一性として実装する。） **/ }
    override fun hashCode(): Int { /** 省略 **/ }
}

// その他の実装は省略

ユースケースの実装

上記ドメインオブジェクトを利用してユースケースを実装すると以下のようになります。

class RecipeCommandService(
        private val ingredientRepository: IngredientRepository,
        private val ingredientCategoryRepository: IngredientCategoryRepository
) {
    // 材料カテゴリを追加する
    @Transactional
    fun handle(command: AddIngredientCategoryCommand) {
        val ingredient = ingredientRepository.findBy(command.recipeId)
                ?: throw IngredientNotFound()

        val ingredientCategory = IngredientCategory.create(command.title, command.ingredientItems)
        val newIngredient = ingredient.addCategory(ingredientCategory.id)

        ingredientCategoryRepository.save(ingredientCategory)
        ingredientRepository.save(newIngredient)
    }

    // 材料カテゴリを変更する
    @Transactional
    fun handle(command: ChangeIngredientCategoryCommand) {
        val ingredientCategory = ingredientCategoryRepository.findBy(command.id)
                ?: throw IngredientCategoryNotFound()

        val newIngredientCategory = ingredientCategory.change(command.title, command.ingredientItems)

        ingredientCategoryRepository.save(newIngredientCategory)
    }

    // 材料カテゴリを並び替える
    @Transactional
    fun handle(command: ReorderIngredientCategoriesCommand) {
        val ingredient = ingredientRepository.findBy(command.recipeId)
                ?: throw IngredientNotFound()

        val newIngredient = ingredient.reorderCategories(command.orderings)

        ingredientRepository.save(newIngredient)
    }

    // 材料カテゴリを削除する
    @Transactional
    fun handle(command: DeleteIngredientCategoryCommand) {
        val ingredient = ingredientRepository.findBy(command.recipeId)
                ?: throw IngredientNotFound()

        val ingredientCategory = ingredientCategoryRepository.findBy(command.id)
                ?: throw IngredientCategoryNotFound()

        val newIngredient = ingredient.deleteCategory(ingredientCategory.id)

        ingredientRepository.save(newIngredient)
        ingredientCategoryRepository.delete(ingredientCategory)
    }

    // その他のユースケースは省略
}

問題点

「材料カテゴリを変更する」のユースケースでは、対象の材料カテゴリのみ DB からの取得と保存を行うようになっていますし、「材料カテゴリを並び替える」のユースケースでは、材料カテゴリの ID のみ DB からの取得と保存を行うようになっていますので、非効率と問題視していたことについては解消できているように感じます。
しかし、材料カテゴリの個数管理を材料に持たせた結果、「材料カテゴリを追加する」と「材料カテゴリを削除する」のユースケースでは、材料と材料カテゴリ両方に対してリポジトリでの保存が必要になってしまい、整合性を確保するための処理が利用側に委ねられてしましました。

ドメインイベントを利用した集約の永続化

整合性を確保しつつ効率的に処理するにはどうすれば良いか試行錯誤した結果、ドメインイベントが利用できるのではないかと考えました。
ドメインイベントといっても Event Sourcing を利用するのではなく、State Sourcing で実装します。
集約ルートをリポジトリに渡して集約全体を DB に保存するのではなく、ドメインイベントをリポジトリに渡して変更点のみを DB に保存するというやり方です。
実装例を以下に示します。

ドメインオブジェクトの実装

集約ルートのメソッドは、整合性を確保するためのバリデーションを行い、問題なければ変更後の集約ルートとドメインイベントのペアを返却します。
ドメインイベントには集約内で変更された情報のみを格納するようにします。

// 材料（集約ルート）
class Ingredient private constructor(
        val recipeId: RecipeId,
        val categories: List<IngredientCategoryId>,
        val version: OptimisticLockingVersion
) {
    companion object {
        private const val CATEGORIES_COUNT_MAX = 10

        // 材料を永続領域から復元する
        fun reconstruct(
                recipeId: RecipeId,
                categories: List<IngredientCategoryId>,
                version: OptimisticLockingVersion
        ): Ingredient {
            return Ingredient(recipeId, categories, version)
        }
    }

    // 材料カテゴリを追加する
    fun addCategory(category: IngredientCategory): Pair<Ingredient, IngredientCategoryAdded> {
        return categories.plus(category.id).let {
            require(it.size <= CATEGORIES_COUNT_MAX) {
                "材料カテゴリは $CATEGORIES_COUNT_MAX 個以下でなければなりません。"
            }
            Pair(Ingredient(recipeId, it, version), IngredientCategoryAdded(recipeId, category))
        }
    }

    // 材料カテゴリを並び替える
    fun reorderCategories(orderings: List<Pair<IngredientCategoryId, Int>>): Pair<Ingredient, IngredientCategoriesReordered> {
        val reorderedCategories = // 並び替えの実装は省略
        return Pair(
                Ingredient(recipeId, reorderedCategories, version),
                IngredientCategoriesReordered(recipeId, reorderedCategories)
        )
    }

    // 材料カテゴリを削除する
    fun deleteCategory(categoryId: IngredientCategoryId): Pair<Ingredient, IngredientCategoryDeleted> {
        return categories.minus(categoryId).let {
            Pair(Ingredient(recipeId, it, version), IngredientCategoryDeleted(recipeId, categoryId, it))
        }
    }

    // 楽観的ロックのバージョンを上げる
    fun updateVersion(nextVersion: OptimisticLockingVersion): Ingredient {
        require(nextVersion.isNext(version))
        return Ingredient(recipeId, categories, nextVersion)
    }

    override fun equals(other: Any?): Boolean { /** 省略（recipeId を同一性として実装する。） **/ }
    override fun hashCode(): Int { /** 省略 **/ }
}

// 材料カテゴリ（集約ルート）
class IngredientCategory private constructor(
        val id: IngredientCategoryId,
        val title: IngredientCategoryTitle,
        val ingredientItems: List<IngredientItem>,
        val version: OptimisticLockingVersion
) {
    companion object {
        private const val INGREDIENT_ITEM_COUNT_MAX = 100

        // 材料カテゴリを新規作成する
        fun create(title: IngredientCategoryTitle, ingredientItems: List<IngredientItem>): IngredientCategory {
            validateIngredientItems(ingredientItems)
            return IngredientCategory(
                    IngredientCategoryId.newId(),
                    title,
                    ingredientItems,
                    OptimisticLockingVersion.initial()
            )
        }

        // 材料カテゴリを永続領域から復元する
        fun reconstruct(
                id: IngredientCategoryId,
                title: IngredientCategoryTitle,
                ingredientItems: List<IngredientItem>,
                version: OptimisticLockingVersion
        ): IngredientCategory {
            return IngredientCategory(id, title, ingredientItems, version)
        }

        private fun validateIngredientItems(ingredientItems: List<IngredientItem>) {
            require(ingredientItems.size <= INGREDIENT_ITEM_COUNT_MAX) {
                "材料は $INGREDIENT_ITEM_COUNT_MAX 個以下でなければなりません。"
            }
        }
    }

    // 材料カテゴリを変更する
    fun change(
            title: IngredientCategoryTitle,
            ingredientItems: List<IngredientItem>
    ): Pair<IngredientCategory, IngredientCategoryChanged> {

        validateIngredientItems(ingredientItems)
        return IngredientCategory(id, title, ingredientItems, version)
                .let { Pair(it, IngredientCategoryChanged(it)) }
    }

    // 楽観的ロックのバージョンを上げる
    fun updateVersion(nextVersion: OptimisticLockingVersion): IngredientCategory {
        require(nextVersion.isNext(version))
        return IngredientCategory(id, title, ingredientItems, nextVersion)
    }

    override fun equals(other: Any?): Boolean { /** 省略（id を同一性として実装する。） **/ }
    override fun hashCode(): Int { /** 省略 **/ }
}

ユースケースの実装

ユースケースの実装では、リポジトリから集約ルートを取得し、集約ルートに対する操作の結果として受け取った変更後の集約ルートとドメインイベントをリポジトリに渡して永続化します。

class RecipeCommandService(
        private val ingredientRepository: IngredientRepository,
        private val ingredientCategoryRepository: IngredientCategoryRepository
) {
    // 材料カテゴリを追加する
    @Transactional
    fun handle(command: AddIngredientCategoryCommand) {
        val ingredient = ingredientRepository.findBy(command.recipeId)
                ?: throw IngredientNotFound()

        val ingredientCategory = IngredientCategory.create(command.title, command.ingredientItems)

        val (newIngredient, event) = ingredient.addCategory(ingredientCategory)

        ingredientRepository.save(newIngredient, event)
    }

    // 材料カテゴリを変更する
    @Transactional
    fun handle(command: ChangeIngredientCategoryCommand) {
        val ingredientCategory = ingredientCategoryRepository.findBy(command.id)
                ?: throw IngredientCategoryNotFound()

        val (newIngredientCategory, event) = ingredientCategory.change(command.title, command.ingredientItems)

        ingredientCategoryRepository.save(newIngredientCategory, event)
    }

    // 材料カテゴリを並び替える
    @Transactional
    fun handle(command: ReorderIngredientCategoriesCommand) {
        val ingredient = ingredientRepository.findBy(command.recipeId)
                ?: throw IngredientNotFound()

        val (newIngredient, event) = ingredient.reorderCategories(command.orderings)

        ingredientRepository.save(newIngredient, event)
    }

    // 材料カテゴリを削除する
    @Transactional
    fun handle(command: DeleteIngredientCategoryCommand) {
        val ingredient = ingredientRepository.findBy(command.recipeId)
                ?: throw IngredientNotFound()

        val ingredientCategory = ingredientCategoryRepository.findBy(command.id)
                ?: throw IngredientCategoryNotFound()

        val (newIngredient, event) = ingredient.deleteCategory(ingredientCategory.id)

        ingredientRepository.save(newIngredient, event)
    }

    // その他のユースケースは省略
}

リポジトリの実装

リポジトリは集約ルートと 1 対 1 で作成します。
インターフェースとしては、DB から集約ルートを復元するためのメソッドと、ドメインイベントの内容を DB に保存するためのメソッドを用意します。
DB については、Event Sourcing や CQRS を利用してコマンドとクエリで DB を分けるということはせず、コマンドとクエリ両方で利用する 1 つの DB を RDB で構築します。

具体的な実装は以下の通りです。

• 復元処理
  • DB から集約に関係するテーブルを結合してデータを取得し、集約ルートのオブジェクトを生成し、返却します。
• 保存処理
  • 受け取ったドメインイベントごとに変更内容をのみを DB に保存する処理を実装します。
  • DB に保存する際には、集約ルートが持つ version を利用して楽観的ロックを行い、save() の戻り値としては新たなバージョンに更新した集約ルートを返却します。（戻り値の集約ルートはあまり利用されることはないとは思いますが、アプリケーションサービスの後続処理で利用されることを考慮して返却しておきます。）
  • 受け取れるドメインイベントの型は、対になる集約ルートで生成されるドメインイベントのみとします。（例えば今回の例では、材料で生成するドメインイベントの interface として IngredientEvent を定義しており、材料のリポジトリでは IngredientEvent の実装しか受け取れないようにしています。）

// 材料集約のリポジトリ
class IngredientRepositoryImpl : IngredientRepository {
    override fun findBy(recipeId: RecipeId): Ingredient? {
        val ingredient = // 省略（DB から復元する。）
        return ingredient
    }

    /**
     * イベントの内容を用いて DB 更新する。
     * @throws OptimisticLockingError 楽観的ロックエラー
     */
    override fun save(ingredient: Ingredient, event: IngredientEvent): Ingredient {
        // イベントごとに DB への保存処理を分ける。
        return when (event) {
            is IngredientCategoryAdded -> save(ingredient, event)
            is IngredientCategoriesReordered -> save(ingredient, event)
            is IngredientCategoryDeleted -> save(ingredient, event)
            else -> throw IllegalArgumentException("イベントがサポートされていません。event: ${event.javaClass.name}")
        }
    }

    // 材料カテゴリの追加を保存する。
    private fun save(ingredient: Ingredient, event: IngredientCategoryAdded): Ingredient {
        val currentVersion = ingredient.version
        val nextVersion = ingredient.version.next()

        // 省略
        //   version、nextVersion を用いて楽観的ロックをしつつ、
        //   event が持つ情報を利用して材料カテゴリのテーブルに INSERT する。

        // 新たなバージョンで更新した集約を返却する。
        return ingredient.updateVersion(nextVersion)
    }

    // 材料カテゴリの順番変更を保存する。
    private fun save(ingredient: Ingredient, event: IngredientCategoriesReordered): Ingredient {
        val currentVersion = ingredient.version
        val nextVersion = ingredient.version.next()

        // 省略
        //   version、nextVersion を用いて楽観的ロックをしつつ、
        //   event が持つ情報を利用して材料カテゴリのテーブルの順番カラムを UPDATE する。

        // 新たなバージョンで更新した集約を返却する。
        return ingredient.updateVersion(nextVersion)
    }

    // 材料カテゴリの削除を保存する。
    private fun save(ingredient: Ingredient, event: IngredientCategoryDeleted): Ingredient {
        val currentVersion = ingredient.version
        val nextVersion = ingredient.version.next()

        // 省略
        //   version、nextVersion を用いて楽観的ロックをしつつ、
        //   event が持つ情報を利用して材料カテゴリのテーブルから DELETE し、
        //   材料カテゴリのテーブルの順番カラムを UPDATE する。

        // 新たなバージョンで更新した集約を返却する。
        return ingredient.updateVersion(nextVersion)
    }
}

// 材料カテゴリ集約のリポジトリ
class IngredientCategoryRepositoryImpl : IngredientCategoryRepository {
    override fun findBy(id: IngredientCategoryId): IngredientCategory? {
        val ingredientCategory = // 省略（DB から復元する）
        return ingredientCategory
    }

    /**
     * イベントの内容を用いて DB 更新する。
     * @throws OptimisticLockingError 楽観的ロックエラー
     */
    override fun save(ingredientCategory: IngredientCategory, event: IngredientCategoryEvent): IngredientCategory {
        // イベントごとに DB への保存処理を分ける。
        return when (event) {
            is IngredientCategoryChanged -> save(ingredientCategory, event)
            else -> throw IllegalArgumentException("イベントがサポートされていません。event: ${event.javaClass.name}")
        }
    }

    // 材料カテゴリの変更を保存する。
    private fun save(ingredientCategory: IngredientCategory, event: IngredientCategoryChanged): IngredientCategory {
        val version = ingredientCategory.version
        val nextVersion = ingredientCategory.version.next()

        // 省略
        //   version、nextVersion を用いて楽観的ロックをしつつ、
        //   event が持つ情報を利用して対象の材料カテゴリのテーブルを UPDATE する。

        // 新たなバージョンで更新した集約を返却する。
        return ingredientCategory.updateVersion(nextVersion)
    }
}

まとめ

リポジトリに集約ルートを渡して DB に保存するのではなく、ドメインイベントを渡して DB に保存するようにすることで、ユースケースの実装に整合性を確保するための処理が委ねられることがなく、リポジトリで最小限の DB 更新で済むようになったのではないかと思います。

また、今回の実装方法の注意点として以下の点が挙げられると思っています。

• リポジトリに渡すドメインイベントは、必ず集約ルートで返却されたものを利用すること。
  • 個別に生成したドメインイベントを渡すことを許可してしまうと、整合性が崩されてしまう恐れがあるためです。
• 最低でも楽観的ロックを行う必要がある。
  • 変更点のみを DB に保存するため、他からの操作とバッティングした場合、整合性が崩されてしまう恐れがあるためです。

ちなみに今回の実装例は GitHub にありますので、よろしければご覧いただければと思います。

2021-10-01 追記

「1 つの材料カテゴリを更新したいだけなのに材料全体を DB から取得して、材料全体を DB に保存しなければならず非効率である。」という問題を解決したいと思い、集約を分割しつつ集約間の整合性を利用側に委ねることなく確保するためにはどうすれば良いかを考えた末、今回の実装方法に至りましたが、結果として、リポジトリの実装で他の集約に関するテーブル更新が必要になってしまいました。（材料リポジトリで材料カテゴリ集約のテーブル更新をしている。）

コメントいただいた結果、やはり強い整合性を確保したいのであれば同じ集約にするのが良いという結論になりました。
同じ集約にした場合の実装例は下記 v4 パッケージにあります。
https://github.com/TakashiOnawa/ddd-aggregate-sample/tree/main/src/main/kotlin/com/example/dddaggregatesample/v4

材料と材料カテゴリを同じ集約にした場合、元々の「1 つの材料カテゴリを更新したいだけなのに材料全体を DB から取得して、材料全体を DB に保存しなければならず非効率である。」という問題が解決できるか、と考えると、DB への保存についてはドメインイベントを利用して差分だけ DB 更新することで解決可能ですが、DB からの取得についてはやはり材料全体の取得が必要であるため解決できません。

ただ今回のケースだと、最大個数を、材料カテゴリは 10 個、材料要素は 100 個に設定してはいるものの、実際にはもっと少ない数になるとは思いますので、材料全体を取得することは許容するという判断も可能だと思います。

それでもメモリやパフォーマンスを気にしなければならないような場合は、集約を分割し、ユースケースの実装で集約間の整合性を確保するのもやむなしになるのかなと思います。

参考

• エリック・エヴァンスのドメイン駆動設計
• 実践ドメイン駆動設計
• CQRS/ESによって集約の境界定義を見直す
• DynamoDBを使ったCQRS/Event Sourcingシステムの構築方法(言語・F/W非依存)
• ドメイン駆動設計 モデリング/実装ガイド
• ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本