エリック・エヴァンスのドメイン駆動設計を読んでいる ( 6 )

第4章ドメインを隔離する

- ソフトウエアの中で、ドメインに関係した実装部分は一部

- その一部が、技術的な解決部分に埋もれてはいけない

- それを埋もれないように分離するアーキテクチャが「レイヤ化アーキテクチャ」

　情報の表示、入力の受付/解釈
　MVCでいうV。

・アプリケーション

　ビジネスルールなどを含まず、ほかのレイヤ（ユーザーインターフェースとドメインなど）の仲介をする。

　MVCでいうC。

　言わずもがな、ドメイン層。
　MVCでいうM(だが、MVCはドメインとインフラストラクチャが分離されてないので、厳格ではない）

・インフラストラクチャ

　例えば、DB/S3/メールなど。技術的な解決部分。
MVCでいうM(だが、MVCはドメインとインフラストラクチャが分離されてないので、厳格ではない）

レイヤは下位層にのみ依存するようにすること。

レイヤを関連づける

とはいえ、実際には下のレイヤー（例：インフラストラクチャからドメイン）につなげたいという要求は普通にある。

疎結合であるべきだが、やるならコールバックやオブザーバーパターンが使われる
また、ドメイン層だけ隔離できれば、アプローチは他のものでも良い
ただ、他のレイヤの機能を直接的に支援する仕組みのあるフレームワークもある。全てのドメインオブジェクトに抽象基底クラスを用意するなど。
ActiveRecordの事だね…
→これらは、ドメインモデルの設計に大きく影響する

アーキテクチャフレームワーク

実装に使うフレームワーク選択は重要

ドメイン層はモデルが息づく場所

ドメイン駆動設計が求めるのは、「ドメイン層」があること。

ドメイン層は、モデルとそれに関わる設計の全てが現れる場所。

ソフトウエアで表現されたモデル

値オブジェクト、エンティティ、サービスのどこに寄せるかは極めて難しい。

そもそも値オブジェクト、エンティティの詳しい用語説明この本のここまでに無かったよね…。

突然説明も無しに登場してきた感があるが、ググった結果こちらに説明があった。

エンティティ
一意なものを表す。一意な識別子を持っている。
長期にわたって変更（ライフサイクル）を管理する必要があるもの。
別々の実装をまたいで追跡されるようなもの。

社員。識別子は社員番号
記事。識別子は年度と記事連番
商品。識別子はJANコード
値オブジェクト
変更（ライフサイクル）を管理する必要がないもの。
色、誕生日、電話番号、指名など。
対象の存在そのものでなく、対象のパラメータ的なものという事かな？

また、これらに含めずに「アクション」「操作」として持つ方が良いものもある。

なんかふんわりした話ばっかりでわかりづらい…。後の章で細かい説明あるっぽいしここまで。