要約 †
古山さんの要約はこちら
- [文脈の説明]
- P104-1
- P104-2
- もっとも明確で現実的な設計は，どのオブジェクトにも属さないような操作を含みます．それは SERVICE としてモデルに含めるのが自然です．
＊＊＊
- [問題についての説明]
- P104-3
- ドメインには重要だけれども，ENTITI にも VALUE OBJECT にも属さない操作が存在します．それらは本質的に活動や行動であり，「もの」ではありません．モデリングパラダイムがオブジェクトなので，それらをオブジェクトの中にフィットさせようとします．
- P104-4
- よくある間違いは，振る舞いを適切なオブジェクトにフィットさせることを簡単にあきらめすぎて，手続き的なプログラミングなってしまうことです．
- P104-5
- サービスはモデルオブジェクトのふりをすることがあります．それは「Manager」などで終わる名前に行き着きます．それらは固有の状態も意味も持ちませんが，少なくとも本当のモデルオブジェクトを台無しにすることのない解決策です．
- 問題サマリ
- P105-1
- ドメインの概念の一部はオブジェクトによるモデルには不自然です．
- それはモデルに基づくオブジェクトをゆがめるか，意味のない人工的な成果物を加えることになります．
- [問題の解決方法についての説明]
- P105-2
- SERVICE は独立したインタフェースとして提供される操作で，ENTITIES や VALUE OBJECTS のような状態をカプセル化したものではありません．
- P105-3
- ENTITIES や VALUE OBJECTS とは異なり，SERVICE は純粋にクライアントのために何をするかで定義され，その名前は名詞よりも動詞で命名される傾向にあります．操作の名前は UBIQUITOUS LANGUAGE を語源とすべきであり，そのパラメータや結果はドメインオブジェクトであるべきです．
- P105-4
- SERVICES は思慮深く使い，ENTITIES や VALUE OBJECTS から全ての振る舞いをはぎ取ってはなりません．しかし，活動がドメインの重要な概念である場合，SERVICE は自然に MODEL-DRIVEN DESIGN の一部となります．
- P105-5
- よい SERVICES には三つの特性があります．
- その操作は ENTITY や VALUE OBJECTS の一部としては不自然なドメインの概念に関連する．
- そのインタフェースはドメインモデルの他の要素に関連して定められる．
- その操作はステートレスである．
- P105-6
- SERVICE の実行は，グローバルにアクセスできる情報を参照し，更新します．
- 解決方法サマリ
- P106-1
- ドメインにおける重要なプロセスや変換が ENTITY や VALUE OBJECT の自然な責務ではない場合は，その操作を独立したインタフェースとして定義された SERVICE としてモデルに追加してください．
- モデル言語に関連するインタフェースを定義し，その操作の名前が UBIQUITOUS LANGUAGE の一部であることを確認してください．
- SERIVCE はステートレスにしてください．
＊＊＊
- P106-2
- P106-3
- 多くの文献で論じられる SERVICES は純粋に技術的でインフラストラクチャ層に属するものです．ドメインおよびアプリケーション層の SERVICES はインフラストラクチャ層の SERVICES と協調します．
- 例：銀行では，口座からの引き落としに失敗した場合に電子メールを送信するかもしれません．
- P106-4
- P106-5
- ドメイン層およびアプリケーション層の多くの SERVICES はENTITIES や VALUE OBJECTS の上に構築され，スクリプトのように振る舞います．多くの場合，ENTITIES や VALUE OBJECTS はドメイン層を便利に操作するための手段を提供するには粒度が細かすぎます．
- P107-1
- 銀行の「資金移動」の例．その SERVICE は自身では多くのことは行わず，二つの Account オブジェクトに依頼します．しかし，それは二つの口座といくつかのグローバルなルールを含むので，transfer 操作を Acount オブジェクトに与えるのは不適切です．
- P107の表
粒度 †
- P108-1
- 概念を SERVICE としてモデリングすることによる表現力の豊かさを協調しましたが，このパターンがドメイン層が提供するインタフェースの粒度を制御し，クライアントから ENTITIES や VALUE OBJECTS を分離する手段としても価値があります．
- P108-2
- 中間的な粒度を持つステートレスの SERVICES は，シンプルなインタフェースの背後に重要な機能をカプセル化するので，大きなシステムでの再利用も容易です．
- P108-3
- 思慮深く導入されたドメインサービスは，レイヤ間の明確な線引きに役立ちます．
- P108-4
- SERVICE は，ドメインの概念をもっとも自然に表現する方法となることがあります．
- P108-5
- J2EE や CORBA などの分散システムアーキテクチャでは，SERVICES は特別な公開メカニズムを提供します．
- SERVICES へのアクセスを提供する手段は，どのような責務を与えるかというデザイン上の決定に比べれば重要ではありません．
古山さんのつぶやき †
- 僕がいま所属しているプロジェクトでは、business.domainパッケージを切ってそこにentity/value objectを置き、business直下にserviceとなるインターフェイスを置いています。（business.implに実装を配置）。別途ユースケース固有の実装を置くfacadeパッケージもある。
- サービスとエンティティを分離できる設計なんてできるの？ドメインを持つアプリケーションからドメインを抜いたらコンパイル通るわけが。。。
- 依存関係逆転の原則とかでがんばればどうにかなるかもしれないですね。でもアプリケーション固有なドメインなら努力する価値が。。。
- エンティティ/サービスに実装する振る舞いの切り分けとしては、戻り値がエンティティの保持する変数/保持する変数からの導出項目となるか、エンティティとなるか、あたりが使えるかも知れないと思いました
- active record全否定ではないですが、ドメインの知識=エンティティのプロパティ的な発想は結合テストとか保守の工数を考慮すると単なるアンチパターンのように思います
- 人工的なドメインというのは多分、アナリシスパターンで出てくるlegとか、aggregationの仲介役となるようなやつらですね。実際のドメインモデルでも、legとかhogehogeAttributeとか、ドメインをうまく取り扱えるようにするやつらを見かけます。(entityとかvalue objectの話ですが)
小林 (koichik) のつぶやき †
- ここでの SERVICES は ENTITIES などより粒度が大きく，上位層からドメイン層へのインタフェースとなるようなものという印象．S2JDBC などでエンティティと 1 対 1 対応するような形で作るクラスを Service と呼ぶことになったけど，それとは位置づけが違うような．昔から Service と呼ばれていたクラスの方が近そう．
みんなの突っ込み †
- SERVICES
- 冒頭：
- 強いて言うのもアレですが、「すべてがモノなわけではありません。(Sometimes, it just isn't a thing)」とかでしょうか。
- p.104-4：
- 処理をオブジェクトに割り当てるのを安易に諦めすぎては手続き型になってしまう⇔そうかといって適切ではないオブジェクトに押し込んでも分かりにくくなるだけ
- それで、どっちも良くないよね、ということで次の段落に進むのだと思います。
- p.105-4：
- このパラグラフは、直前の「ステートレス」の説明だと思います。
- 「ステートレス」とは、クライアントがインスタンスの経緯を意識せずに使うことができるということであり、「SERVICE の実行は，グローバルにアクセスできる情報を参照し，更新」するが、ドメインオブジェクトのように振る舞いに影響を及ぼすような状態は持たない。
- SERVICES and the Isolated Domain Layer
- ドメインレイヤに位置するSERVICEは他のレイヤのSERVICEとは区別する。ということがこの節の主眼だと思います。
- そのうえで、InfrastructureのSERVICE（=Technical SERVICES）との分離は明確なのですが、Application層SERVICEとDomain層SERVICEとの区別をEvansがどうとらえているかはっきりさせておきたいです。
- p.107にある"very fine line"を基準にすると、（既に古山さんの表にありますが、強調の意味でもう一度）
- ドメインのデータをスプレッドシートに吐き出す処理はApplication層のSERVICE。なぜなら、"ファイル形式"はドメインと関係ないし、ビジネスルールが含まれていないから。
- Accountオブジェクトを操作してお金を移動させる処理はDomain層のSERVICE。なぜなら、重要なビジネスルールが埋め込まれているから。
- 整理すると、こういうことでしょうか。
- 「複数のENTITYなりVALUE OBJECTを特定のビジネスルールに従って操作する」という処理は確かにDomain層に存在する。
- Application層はDomain層とユーザーとの間を取り持つ処理を担当する。-- 和智?
- 冒頭は修正しました． -- koichik?
- InfrastructureとApplicationサービスの違いは誰が呼び出すか（エンドユーザならApplication、システムならInfrastructure）？ -- 池田?
