「ドメイン駆動設計モデリング/実装ガイド」を読んだ

booth.pm

まえがき

DDDに関する書籍を今まで読んだ経験がなかったのでとても新鮮でした。

まとめと感想

2章

ユースケース図から始める
次にドメインモデルをまとめた図を作成する

集約や記憶すべき値を定める。そして基本的にイミュータブルなインスタンス（ミュータブルに扱いたい場合は、それを扱うメソッドを意識的に公開する）を通じて、レポジトリに永続化を依頼する。

3章

整合性とトランザクションのために集約を定める

4章

集約・結合度について

以下のスライドを読んだことがあってそれを思い返した。

オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling - Speaker Deck

6章

値オブジェクトについてがむずい。

3分でわかる値オブジェクト - Qiita

一応の理解としては、プリミティブ型だけで表せないattribute（インスタンス変数など）に制限をかけ、イミュータブル（getter無し）にする、というプリミティブラッパー的なものにさらないロジックを化していくことで値オブジェクトを作っていくのかな、という気がした。

抽象でなくドメインという具象に依存することについて、ドメインは変更の度合いが大きいのになんで？という質問について。

「最も重要なドメイン層を独立させて修正させやすくするため」

ドメイン層に依存させることについての自分の感想:

変更が多い箇所に依存させるという設計について、初見は違和感を持った。設計の基本としては、依存はできる限り「抽象」に寄せたほうがいいというのがクリーンアーキテクチャの一つの考え方としてあったと思っていて、それは具象といった変更される機会が多くなりがちなものに依存する構造をとると、ある変更が予期せぬところまで波及するケースが増えるからだ。

けれど、ある意味でドメイン駆動設計の場合は「最も重要なドメイン層を独立させて修正させやすくするため」に加えて、以下２つの理由で「ドメイン層に依存させていいのかもしれない」というふうに思った。というのが、一つはそもそもドメインというものの在り方自体がある意味規定じみていて（というのは、特定の呼び出し方をされるケースしかない？　たとえばインスタンスを作るファクトリーのようなドメインサービスとか。）、そのドメインに依存するというのが、そこまで致命的なケースになりうるということはないと思った。つまり、ドメインに依存しているようで、実際は「ドメインとしてあるべき振る舞いという抽象」に依存するケースが多いのでないかな、とも思うけどどうなんだろう。

それと、もう一つは、ドメインが変更されたとき、いろいろな所に影響が及ぶというのは、「ある意味で健全」なのではないかと思ったからだ。つまり、ドメインというのはある意味でビジネスロジック自体のコード化で、そのビジネスの根幹である部分に「変更がある」とき、その影響は即座に波及してほしい、ということだ。（特にプレゼンテーション層などにおいて。）

もちろん、ドメイン層が変更されたことでDBと接続するミドルウェアなどに影響があるような依存になっているならそれは由々しき事態だが、実際のところ、そこまで影響が及ぶ形で依存させる設計には普通にコードを書いていたらない……と思う。

7章

ユースケース層の戻り値について

シリアライズを使うなど。

8章

CQRSについて

自分のお気持ちだけど、このDDDを読む前から「ActiveRecordってDBからの参照とDBへの書き込みを同じモデルを通じて行っているけど、そのせいで一つのモデルにめちゃロジック増えるときあるよな」と思っていたので、こういう概念あったんですね、という気持ちになった。つまり参照のためのモデルという概念。