「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」まとめ前編

「エリック・エヴァンスのドメイン駆動設計をちゃんと読んでないなー」、「読まなきゃなー」と思い、その準備として「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」を読んだので内容まとめ。

「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」とは？

ドメイン駆動設計を手軽に理解したい初心者向けの書籍。この書籍のゴールは、ドメイン駆動設計を理解するために必要な前提知識や概念、用語を理解し、ドメイン駆動設計の本質を学ぶための準備を完了させること。

エリック・エヴァンスのドメイン駆動設計を読む前の準備段階として、この「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」を読むと良いと言われています。

1章 ドメイン駆動設計とは

ドメインの知識に焦点をあてた設計手法。

ソフトウェア開発におけるドメインは「プログラムを適用する対象となる領域」のこと。「ドメインが何かではなく、ドメインに含まれるものが何か」が重要。

ソフトウェアの目的は利用者のドメインにおける何らかの問題解決であり、そのためには、利用者の考えや視点、取り巻く環境、直面している問題を正確に理解する必要がある。

「知識に焦点をあてる」ということは、ドメインの概念や事象を理解して、その中から問題解決に役立つものを抽出して得られたものをソフトウェアに反映していくということ。

2章 値オブジェクト

値オブジェクトはドメインオブジェクトの一種。システムに登場する単価や商品番号、IDといったシステム固有の値を表現するために定義されたオブジェクトのこと。

システムに最適な値が必ずしもプリミティブな値とは限らない。必要とされる処理に応じて適切な値の表現があるはずと思ったら値オブジェクトを定義することを検討すると良い。

値オブジェクトを利用することで表現力が増し、ロジックの散在を防ぐことができる。

値の性質

値オブジェクトは「値」であるため、値の性質を持つべき。

特に気をつけるべきと思った点は、交換可能と不変。値オブジェクトは自身の状態を変更するふるまい（メソッド）を持つべきではない。値を変更したい場合は代入による値の交換を行う。

値オブジェクトにする基準

どこまで値オブジェクトにするかはコンテキストによる。

著者は「そこにルールが存在しているか」、「それ単体で扱いたいか」を重要な判断基準としている。

3章 エンティティ

エンティティとは、属性ではなく同一性によって識別されるドメインオブジェクト。
※ ER図のエンティティとは意味が異なるので注意。

エンティティの性質

エンティティは属性ではなく同一性によって識別されるドメインオブジェクト。

エンティティと値オブジェクトは共にドメインモデルの実装であるドメインオブジェクトであるが、性質は真逆にしたようなもの。

値オブジェクトは不変であり、値の交換は代入を使うべきだったため、値を変更するふるまいを持つべきではなかった。一方、エンティティの属性は可変であるため、ふるまい（メソッド）を通じて属性を変更するべき。

エンティティにする判断基準

値オブジェクトもエンティティもドメインの概念を表現するドメインオブジェクトである。値オブジェクトとエンティティのどちらにするかを判断する基準の1つに「ライフサイクルが存在し、そこに連続性が存在するか」がある。

例えばユーザーには、ユーザー登録 → ユーザー情報の変更 → 退会というライフサイクルがあり、連続性のある概念と言える。

もし「ライフサイクルを持たない」 or 「システム上ライフサイクルを表現する意味が無い」場合には値オブジェクトとして扱うと良い。

4章 サービス

ソフトウェアにおけるサービスとは「クライアントのために何かを行うオブジェクト」

ドメインサービスは自身の振る舞いを変更するようなインスタンス特有の状態を持たないオブジェクトで、値オブジェクトやエンティティに記述すると不自然になってしまうふるまいを定義する。（複数のドメインにまたがる処理などはドメインサービスが使える可能性大）

ドメインサービスもドメインモデルのコード上の表現であり、括りとしては値オブジェクトやエンティティと同一。そのため、ドメインサービスは入出力（DB操作）を伴う処理を取り扱わないようにすべき。

5章 リポジトリ

リポジトリはデータストアにまつわる、永続化（保存）や再構築（復元）を担う。

オブジェクトのインスタンスを保存・取得したいときは、直接データストアに読み書きするのではなく、リポジトリに依頼する。複雑になりがちなデータストア操作をリポジトリに任せることで、ドメインオブジェクトの見通しを良くすることができる。

リポジトリが扱うデータストアはRDBでもNoSQLでもファイルでも何でも良い。むしろデータストアの差し替えを容易にしてくれるもの。

type IUserRepository interface {
	Find(id UserID) (*User, error)
	Save(u *User) error
}

リポジトリのインターフェイスを定義しておき、MySQLを使うリポジトリを実装する。もしMongoDBを使うことになれば、新たにMongoDBを使うリポジトリを実装すれば差し替えが容易。メモリ上に保存するリポジトリを実装しておいて、テストのときにはこのリポジトリを使うとしておけば、面倒なテスト用DB構築処理も不要になる。

リポジトリに定義されるふるまい

リポジトリの責務はドメインオブジェクトの永続化・再構築であり、ドメインのルールをリポジトリに実装するべきではない。

リポジトリの永続化のふるまいは、永続化を行うオブジェクトを引数に取る。

type IUserRepository interface {
	Find(id UserID) (*User, error)
	Save(u *User) error
	UpdateName(id UserID, name string) error // <- NG
}

値を更新したい場合は、エンティティに属性を変更するように依頼して、更新後の状態をリポジトリで永続化する。

↓イメージ

user.ChangeName(name)
repository.Save(user)

再構築（データ検索）のふるまいは基本的には識別子による検索メソッド。（例: FindByID）

ただし、データ検索系のふるまいにはパフォーマンス問題もあるため、識別子以外で検索するメソッドを状況に応じて定義する。（例: ユーザー名で検索したいときにはFindByName を定義する）

6章 アプリケーションサービス

ドメインオブジェクトを組み合わせてユースケースを実現するものがアプリケーションサービス。ドメインオブジェクトが行うタスクの進行を管理し、ソフトウェア利用者の問題を解決に導くもの。

アプリケーション固有の機能・ふるまいを実現するのがアプリケーションサービス。

ドメインオブジェクトを公開する？しない？

例えば、ユーザー取得処理を行うアプリケーションサービスで取得したユーザーを返却するとき、「ユーザーのドメインオブジェクトをそのまま返すかどうか」という話。

ドメインオブジェクトを返却する（公開する）場合、コードはシンプルになるが、アプリケーションサービス以外からドメインオブジェクトのふるまい（メソッド）を呼び出せ、ドメインオブジェクトに対する多くの依存が生まれやすくなる。（本来、ドメインオブジェクトのふるまいを呼び出す役目はアプリケーションサービスの役目）

解決策は、ドメインオブジェクトを返却ドメインオブジェクトの代わりに、データ転送用オブジェクト（DTO, Data Transfer Object）にデータを移し替えて返却する。

// Userのデータを公開するためのオブジェクト（DTO）イメージ
type UserData struct {
    id UserID
    Name string
    Age int
}

func NewUserData(u User) UserData {
    return UserData{...}
}

ドメインのルールを記述しない

アプリケーションサービスはドメインオブジェクトのタスク調整に徹するべきで、ドメインのルールを記述すべきではない。同じようなコードを点在させることにつながる。

ドメインにふるまいをもたせたり、ドメインサービスを用意して、アプリケーションサービス内にドメインルールを記述しないようにする。

サービスは状態をもたない

サービスは自身のふるまいを変化させる目的で状態を保持しない。このような状態をもってしまうと、サービス利用時に今どんな状態なのかを気にする必要が出てしまう。

自身のふるまいを変化させる目的の状態の例

type UserRegisterService struct {
	repo UserRepository // ふるまいを変更しない状態はOK
	sendMail bool
}

func (s *UserRegisterService) Execute() {
	// 色々やる
	if sendMail { // 状態によって処理が変わる

	}
	// 色々やる
}

後編につづく....

今回紹介している書籍