<h2 id="h5fcec0cf90">所感</h2><p>ドメイン駆動設計に関して本格的に学ぼうと思って読んだ1冊<br>ドメインモデルをうまく表現することの利点や技法などをバラバラだった知識をまとめられた印象<br>ビジネスドメインを丁寧にモデリングして扱えるようにしたい<br></p><h2 id="h8c5d914f64">Chapter2</h2><h3 id="h2d0c893345">「システムに最適な値が必ずしもプリミティブな値であるとは限らない」</h3><p>ドメイン固有の値をどう扱うと良いのかにフォーカスすることが大事。<br>イミュータブルであることによりデータの信頼性が向上されるし、それにより交換可能になる。（逆に言うと交換以外で値を変更できない）<br>クラスとして実装していくことで値オブジェクト固有のバリデーションロジックも内包できるというのも扱いやすくなるポイントかなとも思う。<br></p><h3 id="h5090a00f8c">値オブジェクトとして扱う基準</h3><p>また、値オブジェクトとして扱うべきかどうかの判断基準として「そこにルールが存在しているか」「それ単体で取り扱いたいか」という点を筆者が重視しているという点も印象に残った。<br>ドメイン内で特別視されている（ドメイン固有の呼び名が付いているなど）の場合は、値オブジェクトになり得るのかなと思った。<br><br>値オブジェクトに関しては下記のpodcastもとても参考になる。<br><a href="https://anchor.fm/textafm/episodes/2--The-Power-of-Constraints-ejufu0" target="_blank" rel="noopener noreferrer">https://anchor.fm/textafm/episodes/2--The-Power-of-Constraints-ejufu0</a><br></p><h2 id="h93ba759808">Chapter3</h2><h3 id="h13f1e49b2f">値の同一性</h3><ul><li>エンティティは識別子(ID)で同一性を判断</li><li>値オブジェクトは値で同一性を判断<ul><li>別のオブジェクトだとしても値が同じであれば同一とみなす</li></ul></li></ul><p><br></p><h3 id="h53c5bce5d7">エンティティの判断基準</h3><p>「ライフサイクルが存在し、そこに連続性が存在する」ことがエンティティかどうかの基準。<br>作成されて誕生し、削除されて死を迎える。つまりCRUD処理が発生し得る可変なオブジェクト。<br>値オブジェクトは不変であるため、エンティティではないということが分かる。<br></p><h3 id="h594938b0f9">ドメインオブジェクトを定義するメリット</h3><p>印象に残ったのは「仕様書というのはマクロな要件については有効であってもミクロな要件については無力であることが多い」ということ。<br>その通りであるし、そこまで記述する必要がないからそうなっているはず。<br>だからこそ、コードからその要件を汲み取りやすくしておく必要があるなと再認識した。<br>クラスにドメインオブジェクトのルールを記述して凝集度は高く保つというのは、ドキュメンテーションという文脈においても重要。<br></p><h2 id="ha5af9db5f8">Chapter4</h2><h3 id="hddaa2692b7">サービスへのロジック切り出しはドメインモデル貧血症を引き起こす</h3><p>ドメインモデルの振る舞いをサービスに切り出しすぎると、ドメインモデルがデータだけを保持している無口なオブジェクトになってしまう。それによってドメインモデル自身が語るべきことを語っていない状態が出来上がってしまう。<br>データと振る舞いが点在してしまうことで可読性や保守性に欠けてしまう。<br>そうならないために、ドメインモデルに不自然な振る舞いのみサービスに切り出すことが重要。<br>複数のモデルを横断する操作を行う際など、ドメインモデル固有ではないロジックが出てきた場合は検討の余地あり。<br></p><h2 id="h3172a3f7da">Chapter5</h2><h3 id="h3a0df8ba04">ビジネスロジックをより純粋なものに昇華する</h3><p>リポジトリパターンを利用して永続化処理を抽象化して隠蔽することで、ビジネスロジックを簡潔にできる。<br>自分の会社のフロントエンドアプリケーションはリポジトリパターンを利用しており既知の知識としてある。<br>だからこそ今一度下記のようなアンチパターンを実装してしまわないように意識したい。<br><a href="https://qiita.com/mikesorae/items/ff8192fb9cf106262dbf" target="_blank" rel="noopener noreferrer">https://qiita.com/mikesorae/items/ff8192fb9cf106262dbf</a><br></p><h2 id="h442fcfdf7d">Chapter6</h2><h3 id="h9937c71719">アプリケーションサービスはオブジェクトの操作に徹する</h3><p>ドメインロジックの責務外の振る舞いを記述することに徹する。<br>サービスオブジェクトはロジックが雑多になりがち（ドメインロジックが記述されてる / 責務が複数等）なので、今一度サービスクラスを作る際は注意したいと思う。<br><a href="https://qiita.com/joker1007/items/25de535cd8bb2857a685" target="_blank" rel="noopener noreferrer">https://qiita.com/joker1007/items/25de535cd8bb2857a685</a><br></p><h2 id="h144df606cc">Chapter7</h2><h3 id="h17650846c2">依存を避けるよりコントロールせよ</h3><p>抽象に依存することが重要。依存関係逆転の原則。<br>抽象に依存することで変更箇所が最小になる。改めて思うのは良い設計は変更容易性が担保されていること。<br></p><h2 id="h200703e706">Chapter12</h2><h3 id="ha8b99f80ff">オブジェクトの境界線が秩序をもたらす</h3><p>デメテルの法則（最小知識の原則）を元にコード設計する。<br>Wikipediaによると、デメテルの法則の基本骨子は下記である。</p><blockquote>基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべき</blockquote><p><a href="https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%A1%E3%83%86%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87" target="_blank" rel="noopener noreferrer">https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%A1%E3%83%86%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87</a><br><br>つまり、他のオブジェクトの情報（どういう状態/値であるのか等）を知らなくて良いということ。<br>「尋ねるな、命じろ」というソフトウェアの格言があるが、その通りに設計していけばルールが漏れ出すのを防げる。<br>変更が面倒な時は大体同じロジックが書かれているので、改めて意識してコードを書いていきたい。<br>下記資料の図が分かりやすい。<br><a href="https://qiita.com/TakeshiFukushima/items/0b16aef3d320a2ccb7c3#%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87%E3%81%8C%E5%AE%88%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E4%BE%8B" target="_blank" rel="noopener noreferrer">https://qiita.com/TakeshiFukushima/items/0b16aef3d320a2ccb7c3#%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87%E3%81%8C%E5%AE%88%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E4%BE%8B</a><br></p><h2 id="h7a3b06c7df">Chapter13</h2><h3 id="h642977dc12">仕様オブジェクトがドメインルールの点在を防ぐ</h3><h4 id="hacbbee1047">仕様オブジェクトについて</h4><p>ドメインの重要なルールだが処理が複雑になってしまうロジックを格納するオブジェクト<br>目的としては、ロジックの点在を防ぐこと。<br>例えば、こういったロジックはサービス層で実装されがちだが、それだとドメインルールが点在してしまう。<br>そういった状況を防ぐために仕様オブジェクトでロジックをラップする。<br></p><h4 id="h3f4f4f9aaf">リポジトリのフィルターとしても機能する</h4><p>リポジトリに仕様オブジェクトを渡してメソッドを呼び出すようにすることで、ドメイン知識を記述せずに済むようになる。<br></p><pre><code>// 仕様オブジェクト
public class CircleRecommendSpecification {
&nbsp;&nbsp;private readonly DateTime executeDateTime;

&nbsp;&nbsp;public CircleRecommendSpecification(DateTime executeDateTime) {
&nbsp;&nbsp;&nbsp;&nbsp;this.executeDateTime = executeDateTime;
&nbsp;&nbsp;};

&nbsp;&nbsp;public bool IsSatisfiedBy(Circle circle) {
&nbsp;&nbsp;&nbsp;&nbsp;if(circle.CountMembers() &lt; 10) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return false;
&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;return circle.Created &gt; executeDateTime.AddMonths(-1);
&nbsp;&nbsp;};
}

// リポジトリ
public class CircleRepository: CircleRepository {
&nbsp;&nbsp;private readonly ICircleRepository circleRepository;
&nbsp;&nbsp;private readonly DateTime now;
&nbsp;&nbsp;...
&nbsp;&nbsp;public CircleGetRecommendResult GetRecommend(CircleGetRecommendRequest request) {
&nbsp;&nbsp;&nbsp;&nbsp;var circleRecommendSpecification = new CircleRecommendSpecification(now);
&nbsp;&nbsp;&nbsp;&nbsp;// リポジトリに仕様を引き渡して抽出(フィルタリング)
&nbsp;&nbsp;&nbsp;&nbsp;var recommendCircles = circleRepository.Find(circleRecommendSpecification)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.Take(10)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.ToList();
&nbsp;&nbsp;&nbsp;&nbsp;return new CircleGetRecommendResult(recommendCircles);
&nbsp;&nbsp;};
}</code></pre><p><br></p><h2 id="hf6a55646d4">Chapter14</h2><h3 id="h7e510f830b">レイヤーの隔離と責務の分割</h3><p>本書ではドメイン駆動設計がアーキテクチャに求めることは、ドメインオブジェクトが渦巻くレイヤーを隔離して、ソフトウェア特有の事情からドメインオブジェクトを防衛することと説明されている。<br>レイヤードアーキテクチャやクリーンアーキテクチャなどのアーキテクチャも依存の方向を定めて、レイヤーごとに責務を分割している。ドメイン駆動設計の文脈上で最も重要なのはドメインの隔離を促すこと。<br></p><h2 id="h9c70a17397">Chapter15</h2><h3 id="hee5f67d1d8">軽量DDDに陥らないこと</h3><p>デザインパターンなどを盲目的に利用してそれで終わらないこと。<br>重要なのはドメインの本質に向き合い続けること。ユーザーを知り対話を続けドメインを改善していくことを意識したい。<br></p><h2 id="ha214098e44">まとめ</h2><p>依存の方向性 / 責務の分割 / ロジック隠蔽を意識したいと思った。<br>パターンはある程度分かったが、エリックエヴァンスの書籍を読んで根本的な思想の部分を知りたい。</p>

Kdevlog

【読書ログ】ドメイン駆動設計入門: ボトムアップでわかる!ドメイン駆動設計の基本