-
Notifications
You must be signed in to change notification settings - Fork 5
vol7_20140601_事前疑問質問
第７回ドメイン駆動設計読書会@大阪 http://dddosaka.doorkeeper.jp/events/11413 の事前質問・疑問書き込みWiki（書き方、内容自由）
- 「第２部モデル駆動設計の構成要素」最初から
- 「レイヤを関係づける」最後まで
基本的には、範囲に該当する疑問・質問を記載しますが、 過去範囲、全般的な疑問・質問でも構いません。
- @kawakawa 第２部の冒頭に、
本書は、オブジェクト指向設計の解説書でもなければ、急進的な設計原理を提案することもない。 ドメイン駆動設計は、伝統的ないくつかの考え方を基に、強調する点をずらしているのだ。 とありますが、強調する点をずらしているとは何を意味するのだろうか。
- → オブジェクト指向分析では、「現実をそのままシミュレートする」とされていた考え方から、読書会vol.6で話題に出た、「概念をそのままモデル化する」というところに力点があるのかな、と思いました。(@kuma_nana)
- @kawakawa
「第4章 ドメインを隔離する」の冒頭に、
モデル要素を見た時に1つの体系として理解できる必要がある
とあるが、どういう意味なのか。
- @nyanp
基本的なビジネスルールに関する責務を負っているのはドメイン層であって、アプリケーション層ではない(p.69)
について。図4.1(p.70)の「振り込みか引き落としが失敗した場合には、トランザクション全体が失敗する」というルールも基本的なビジネスルールに見えるが、アプリケーション層に責務が置かれている。エヴァンスの言う「基本的なビジネスルール」とは何か？
第２部の冒頭、p.62
本書の設計スタイルは、「責務駆動設計（responsibility-driven- design）」の原則に従うところが大きい。
ドメインモデルを分析・設計する時に使える手法として「責務駆動設計」があります。責務駆動設計とは、「オブジェクトデザイン（Object Design: Roles, Responsibilities, and Collaborations)」等で紹介されているオブジェクト指向による分析・モデリング手法です。オブジェクトデザインでは、分析によって現れたクラスを責務に分割していく時に6つの「ロールステレオタイプ」を用います。
情報保持役(Information Holder) 構造化役(Structurer) サービス提供役(Service Provider) 制御役(Controller) 調整役(Coordinator) インターフェース役(Interfacer)
エンティティは本来「情報保持役」であり、オブジェクト指向のクラス設計原則（SOLID）に従えば、これ以外の責務を持つべきではありません。（注意深く設計する場合、1つのオブジェクトに複数の責務を割り当てることもできます。） 明らかなことは、何でもかんでもエンティティに詰め込んで賢くするのではなく、責務を見分けて適度に分割すべきということです。
ドメイン駆動設計のパターン（エンティティ、値オブジェクト、リポジトリ、サービス、ファクトリ）やオブジェクトデザインの6つのロールステレオタイプなどを設計の型として用いることで、「良い設計、良いソフトウェア」を実現しやすくなるといえるでしょう。
「はじめに」の箇所にまとめがあったので、kuma_nana が改変を加えて抜き書き。
Rebecca Wirfs-Brockの提唱する責務駆動設計(Responsibility Driven Design，以下RDD)。 RDDは「なぜオブジェクト指向なのか」「そもそもオブジェクトは何なのか」にこだわり，ユースケースを完全に網羅するだけのモデリングではなく，業務全体の「責務(responsibility)」を，設計工程でも考えるモデリング手法。 設計工程でシステムの責務を考えることで，保守・拡張を意識したモデリングが可能となる． しかしながら，RDDは以下の二つの課題を有している． 一点目は，アプリケーションとビジネスの両方に関する責務の混在． 二点目は，ユーザを意識したWebシステムの「あるべき姿」について言及する工程に関しては ，RDDが有効とは言えないこと．
- PofEAA
p.18
しかし、レイヤ化アーキテクチャにおいて最も難しいのは、
必要なレイヤと、各レイヤが行うべき内容を決定することである。