RE:メモ:値オブジェクトの定義と差異について
みなさんもそろそろ牛丼に飽きて、海鮮丼が食べたくなった頃だろうか？
もらえるかはわからないけれどアンサーソングを待たずに、個人的なメモだと書いてある記事に言及するのは無粋かもしれない。しかし、どうしても気になってしまい見過ごせない記述があったのでこれを書くことにした。
気になったのは Learning Domain-Driven Design のバリューオブジェクトについての要約部分についてだ。
かとじゅんさんは同書の Chapter 6. Tackling Complex Business Logic をもとに、次のような感想を書いている。
値オブジェクトは振る舞いとデータを含むドメインモデル(ドメインオブジェクト)である、と示されている
まず気になるのが、ドメインモデルとドメインオブジェクトが同一であるかのような記述だ。しかし、ドメインオブジェクト(Domain Object) という用語はこのチャプターに登場しない。
この感想へ至る根拠として、次のようなチャプター内の記述を参照している。(日本語訳はかとじゅんさんの記事のものではなく、僕の手による抄訳）
Domain Model
The domain model pattern is intended to cope with cases of complex business logic. Here, instead of CRUD interfaces, we deal with complicated state transitions, business rules, and invariants: rules that have to be protected at all times.
ドメインモデルパターンは複雑なビジネスロジックのケースに対処するためのものである。ここでは、CRUDインタフェースの代わりに、複雑な状態遷移やビジネスルール、不変条件などの常に守らなければならないルールを扱う。
Implementation
A domain model is an object model of the domain that incorporates both behavior and data. DDD’s tactical patterns—aggregates, value objects, domain events, and domain services—are the building blocks of such an object model.
ドメインモデルとは振る舞いとデータの両方を取り込んだドメインのオブジェクトモデルである。DDDの戦術的パターン —集約、バリューオブジェクト、ドメインイベント、ドメインサービス— はこのようなオブジェクトモデルのビルディングブロックである。
少なくとも、これらの引用部分では、バリューオブジェクトはドメインオブジェクトであると示されていない。バリューオブジェクトがドメインモデルのビルディングブロックの一つであると記述にとどまっている。
そして、かとじゅんさんのメモでは参照されていないが、このチャプターでは次のようにバリューオブジェクトについても、きっちりと説明されている。
Value object
A value object is an object that can be identified by the composition of its values. For example, consider a color object:
バリューオブジェクトはその値の構成によって識別が可能なオブジェクトである。例えば、色オブジェクトを考えてみよう:
かとじゅんさんがこの記述を見逃したのか、あえて記述しなかったのかは分からないが、バリューオブジェクトがオブジェクトが持つ値によって識別されることが説明されている。その実例として、DDD本の例にもある色オブジェクトの実装の説明が続いている。
また、チャプターの最後の Conclustion にも次のようにな記述がある。
Value objects
Concepts of the business domain that can be identified exclusively by their values and thus do not require an explicit ID field. Since a change in one of the fields semantically creates a new value, value objects are immutable.
Value objects model not only data, but behavior as well: methods manipulating the values and thus initializing new value objects.
ビジネスドメインの概念で、その値によってのみ識別されるため、明示的なIDフィールドを必要としないもの。フィールドの1つを変更すると意味論的に新しい値が作成されるため、バリューオブジェクトは不変である。
バリューオブジェクトはデータだけでなく、同じように振る舞い（値を操作するメソッドや、新しいバリューオブジェクトの初期化）も形式化する。
こちらの説明は先程のものよりもモデリングとしての側面が強いが、どちらもPofEAAと同じように、IDに基づかない値による識別が行われる不変なオブジェクトをバリューオブジェクトと呼んでいることがわかる。
このチャプターの冒頭の History というセクションにあったDDDとPofEAAの関連性についての大変興味深い記述があったので合わせて紹介しよう。
As with both the transaction script and active record patterns, the domain model pattern was introduced initially in Martin Fowler’s book Patterns of Enterprise Application Architecture. Fowler concluded his discussion of the pattern by saying, “Eric Evans is currently writing a book on building Domain Models.” The referenced book is Evans’s seminal work, Domain-Driven Design: Tackling Complexity in the Heart of Software.
トランザクションスクリプトとアクティブレコードパターンと同様に、ドメインモデルパターンも、Martin Fowler の著書 Patterns of Enterprise Application Architecture （エンタープライズアプリケーションアーキテクチャ）で最初に紹介されたものである。Fowler氏はこのパターンについての議論を「Eric Evans氏が現在ドメインモデルの構築に関する本を書いている」という言葉で締めくくっている。参照された書籍はEvans氏の代表作である「Domain-Driven Design: Tackling Complexity in the Heart of Software（エリック・エヴァンスのドメイン駆動設計）」である。
In his book, Evans presents a set of patterns aimed at tightly relating the code to the underlying model of the business domain: aggregate, value objects, repositories, and others. These patterns closely follow where Fowler left off in his book and resemble an effective set of tools for implementing the domain model pattern.
彼の本の中で、Evans氏はコードをビジネスドメインの基本的なモデル（集約、バリューオブジェクト、リポジトリなど）と緊密に関連付けることを目的とした一連のパターンを提示している。これらのパターンは、Fowler氏が著書で書き残した部分を忠実に踏襲しており、ドメインモデルパターンを実装するための効果的なツール群に類似している。
The patterns that Evans introduced are often referred to as tactical domain-driven design. To eliminate the confusion of thinking that implementing domain-driven design necessarily entails the use of these patterns to implement business logic, I prefer to stick with Fowler’s original terminology. The pattern is “domain model,” and the aggregates and value objects are its building blocks.
Evans氏が紹介したパターンはしばしば戦術的ドメイン駆動設計と呼ばれる。ドメイン駆動設計を実装するにはこれらのパターンを使ってビジネスロジックを実装する必要があると考えてしまう混乱を無くすために、私はFowler氏のオリジナルの用語にこだわることを好む。そのパターンは「ドメインモデル」であり、集約とバリューオブジェクトはそのビルディングブロックである。
PofEAAの著者のMartin Fowler氏が最初に世に紹介したドメインモデルというパターンがあり、PofEAAで紹介されたドメインパターンの構築に関して、Eric Evans氏がエリック・エヴァンスのドメイン駆動設計という著書を執筆したという歴史がここには記されている。つまり、PofEAAというデザインパターン集をもとに、DDDはPofEAAののパターンを利用した設計手法として書かれた。ここからDDDのドメインモデルがPofEAAで紹介されたものと同じものであり、ドメインモデルのビルディングブロックとなるバリューオブジェクトも、PofEAAと同じものであることは想像に難くない。
繰り返しになるが、DDDのバリューオブジェクトがドメインオブジェクトの一種だという事実はこのチャプターには直接的には書かれていない。ドメインオブジェクトという単語も扱われていない。さまざまなDDDの本からどれだけ事実を収集しても、既にある用語の意味を変更することが難しいことだけがわかる。