<h2 id="h9707d3a59a">概要</h2><p>本書籍では、オブジェクト指向や設計パターンなどソフトウェア設計に関する基本的な概念が紹介されている。<br>章ごとに読んだ感想を述べていく。<br></p><h2 id="h28de596f4c">CHAPTER1: 小さくまとめてわかりやすくする</h2><p>ソフトウェアは常に変更され得るから、変更しやすいコードを書くには何を意識すべきかがまとめられている。<br>分かりやすさに主眼が置かれており、変数名を明確にしたり、値オブジェクトを使うことやイミュータブルなデータに関して言及されている。<br>「クラス名やメソッド名と業務の用語を一致させること」これはかなり大事。異音同義語があると認識のズレとか生まれやすいし、話していてツラミ感じる。<br></p><h2 id="ha15bdf6dc7">CHAPTER2: 場合分けのロジックを整理する</h2><p>ソフトウェア変更容易性を妨げるのが複雑なロジックなので、簡単に書こうという内容や方法がまとめられている。<br>メソッドに切り出すとか、ifのネスト、ガード節による早期returnなど。<br>switch文などで分けるより、クラス化しロジックをカプセル化して呼び出すだけにすると見通しが良くなるなど。<br>使う側のクラスが使われる先のクラスに関する知識が少ないほど疎結合になって良い。<br>Railsで開発しているとどうしても密結合になりがちなので、改めて意識したいと思った。<br></p><h2 id="ha7493dcb4e">CHAPTER3: 業務ロジックをわかりやすく整理する</h2><p>1,2章が部品レベルの話だったが、この章ではアプリケーション全体の組み立てレベルでのロジックの分かりやすさについてまとめている。<br>ドメインオブジェクトをクラスとして管理していく際に下記のことに気をつける。</p><ul><li>メソッドをロジックの置き場所にする<ul><li>getter / setterメソッドだけになっていないか？（=ドメインモデル貧血症）</li></ul></li><li>ロジックを、データを持つクラスに移動する<ul><li>ロジックが点在していないか？共通化できないか？</li></ul></li><li>使う側のクラスにロジックを書き始めたら設計を見直す</li><li>メソッドを短くして、ロジックの移動をやりやすくする</li><li>メソッドでは必ずインスタンス変数を使う<ul><li>Railsの文脈だとクラス内のカラム等</li><li>受け取った引数だけ使っているのであればそのクラスに定義する意味がない</li></ul></li><li>クラスが肥大化したら小さく分ける</li><li>パッケージを使ってクラスを管理する</li></ul><p><br>上記を組み立てる段階で、プレゼンテーション層にドメインロジックが書かれていないか？アプリケーション層との結合はどうか？等の責務を意識していく。<br>基本的にドメインオブジェクトにロジックをまとめることで凝集性を高める方が好ましい。<br></p><h2 id="hc67bfc2306">CHAPTER4: ドメインモデルの考え方で設計する</h2><p>ドメインの関心事を適切にモデルに落とし込んで独立した単位として扱えるようにする重要性についてまとめられている。<br>ドメイン内のユビキタス言語を定めてクラス名に落とし込むことや、「コト」を中心に考えることで関心事を特定しやすくなるなど。<br>特に学びだったのがドメインオブジェクトの基本設計パターンと業務の関心事パターン<br></p><h3 id="h96db50827d">ドメインオブジェクトの基本設計パターン</h3><ul><li>値オブジェクト<ul><li>数値、日付、文字列などをラップしてロジック整理する</li></ul></li><li>コレクションオブジェクト<ul><li>配列やコレクションをラップしてロジック整理</li></ul></li><li>区分オブジェクト<ul><li>区分の定義と区分ごとのロジックを整理</li></ul></li><li>列挙型の集合操作<ul><li>状態遷移ルールなどを列挙型の集合として整理</li></ul></li></ul><p><br>この4種類で業務ロジックを整理していくと業務ロジックがドメインモデルに集約できる。<br></p><h3 id="hf8f9909063">業務の関心事パターン</h3><ul><li>口座パターン<ul><li>現在の値を表現し妥当性を管理<ul><li>数値の増減や現在の値を保持</li><li>銀行の口座や在庫数量の管理など時系列が重要なパターン</li></ul></li></ul></li><li>期日パターン<ul><li>約束の期日と判断を表現<ul><li>期日が適切に守れているかを管理<ul><li>期限切れの場合はどうするかなどの表現</li></ul></li></ul></li></ul></li><li>方針パターン<ul><li>様々なルールが複合する複雑な業務ロジックを表現</li></ul></li><li>状態パターン<ul><li>状態と、状態遷移できる/できないを表現<ul><li>決済ステータスなどで利用される<ul><li>ある状態ではどうなるべきなのかを表現</li></ul></li></ul></li></ul></li></ul><p><br>上記4種類が主な関心事パターンとして挙げられるが、ドメイン理解をしていくことが適切に関心事を扱えるようになるポイント。<br>異音同義語に注意したい。あと、話を深掘り真の課題を抽出すること。<br></p><h2 id="h934a2ff4fe">CHAPTER5: アプリケーション機能を組み立てる</h2><p>サービスクラスに業務ロジックを書かないようにする。<br>防御的プログラミングの形式で多くのガード節があると、ドメインモデルにロジックを移すかクラスを用意するなりした方が良い。<br>あくまでサービスクラスは処理を呼び出すだけ。尋ねるな命じろ。<br></p><h2 id="hb7145337f9">CHAPTER6: データベースの設計とドメインオブジェクト</h2><p>データベース設計がうまくいくとアプリケーションロジックも書きやすくなる。<br>NOT NULL制約だったり、一意性制約、外部キー制約など。詳細はSQLアンチパターンなどの書籍に譲る。<br>というよりDB設計の細かい話より、ドメインの中でテーブル単位をどう切り分けるのかという話の方が重要。<br>「コトの記録」を徹底すると本書には書かれている。<br>実体があるものはモデリングしやすいが、実体の無いものこそ業務ロジックの中ではモデリングすることが大事。<br>texta.fmというラジオでも和田さんが同じことをおっしゃっていた。<br></p><h2 id="h893e2c96ed">CHAPTER7: 画面とドメインオブジェクトの設計を連動させる</h2><p>汎用画面は複数の関心事が混ざっておりロジックを複雑にしてしまう。<br>何事も関心事の分離が肝とあるが、ビジネスサイドからは1つの画面で全部行いたいという要望もあるので落とし所は難しいなと思う。<br>逆に言うと、1つの画面で共通の関心事をまとめられていないという側面もあるのかもしれない。<br>複数の関心事が混ざっていることだけでなく、同じ関心事が複数画面に点在していないかも意識できると良さそう。<br></p><h2 id="h5645107752">CHAPTER8: アプリケーション間の連携</h2><p>APIの粒度を適切に保つことが再利用性や利用容易性を高める。<br>本書では大は小を兼ねるAPIはビジネスの発展を阻害するとあるが、まさにその通りだと思う。<br>ユースケース上では不要なパラメータや戻り値など、複雑にする要因があると連携がスムーズにいかない。<br>将来的な拡張性も難しくしてしまうと感じる。<br>関心事の不一致が起きていないかどうかはこういう場面でも意識したい。<br></p><h2 id="h75d5aa7c28">CHAPTER9: オブジェクト指向の開発プロセス</h2><p>オブジェクト指向らしく分析と設計を一体にすることで、変更が楽で安全なソフトウェア開発を進められる。<br>業務ロジックをドメインモデルに集約して整理することが肝。<br>分析工程と設計工程を分割せずに一貫して行うことや、コードが自己文書化すべき等の記載がある。<br>兎にも角にもドメインを深く理解してモデリングすることが大事。<br></p><h2 id="ha9422fdb63">CHAPTER10: オブジェクト指向設計の学び方と教え方</h2><p>オブジェクト指向設計の考え方を習得するには、リファクタリングが手っ取り早い。<br>コードの重複や巨大なメソッド/クラス、引数が多すぎるメソッドなどをリファクタリングすることでなぜ使いやすくなるのかを肌で感じることが大事。<br>話は少し逸れるが、最近は脱オブジェクト指向が主流になりつつあるような気がするので別途ブログにまとめたい。<br></p><h2 id="ha214098e44">まとめ</h2><p>再利用性が高くDRYなコードを書くのはもちろん、ドメインを適切にモデリングすることを意識したい。</p>

【読書ログ】現場で役立つシステム設計の原則

<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

【読書ログ】現場で役立つシステム設計の原則

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