設計 on blog.kyu08.com

『CQRS Documents by Greg Young』を読んだ

Mon, 12 Jan 2026 00:27:58 +0900

CQRSに興味があったのでGreg Young氏のCQRS Documentsを読んでみた。

https://cqrs.wordpress.com/wp-content/uploads/2010/11/cqrs_documents.pdf

CQRSに興味を持ったきっかけ

ドメイン層のメンテナビリティの重要性を感じる中で、ドメイン層は書き込み系の振る舞いだけを担い、読み取り系の責務は別のモジュールに移譲してしまった方がドメイン層をシンプルに保てて良いのではないかと考えるようになった。¹

それってCQRSってやつじゃね？と思ったのでまずは原典に近いドキュメントを読んでみることにした。²

ここからはCQRS Documentsの内容をまとめていく。

“A Stereotypical Architecture”: 典型的なアーキテクチャ

“A Stereotypical Architecture"として、典型的なアーキテクチャが紹介されている。CQRS Documentsではこのアーキテクチャに対して段階的にCQRSを導入していく形で説明が進んでいく。

CQRS Documents by Greg Young P2より引用

このアーキテクチャではシステムはCRUDのみの機能を持ち、クライアントとは常にDTOを介して通信する。

おそらくクライアントがUpdateUserNameのようなエンドポイントに更新後のユーザーネームだけを渡すのではなく/userに更新後のDTOを丸ごと渡す、というようなことだと思われる。

サーバー側では受け取ったDTOをドメインオブジェクトに詰め替えてバリデーションを行い、永続化する。

このような設計ではアプリケーションサービスの責務はDTOとドメインオブジェクトの詰め替えに終始し、ドメイン層はバリデーションを主な責務として受け持つ。データの更新方法はクライアントに委ねられてしまうため、ドメイン知識の一部がクライアント側に漏れ出してしまう。

このようなアーキテクチャでは簡潔性によってオンボーディングコストが低くなるメリットがある代わりに、次のような課題が存在する。

スケーリング: 一般的なシステムでは読み取り操作は書き込み操作よりも2桁以上多い。読み取り操作から見ると非正規化されたデータ構造が適しているが、書き込み操作から見ると正規化されたデータ構造が適している。これらを単一のDBで扱おうとすると垂直スケーリングが必要になるが、垂直スケーリングには非常に高額なコストがかかる。
DDD適用の困難さ: この設計ではAPIがデータ指向のインターフェースを持つため、システム全体がCRUDの4つの動詞に縛られる。（データの更新方法がクライアントまたはユーザー側に漏れ出ておりドメイン知識をソフトウェアで表現することが難しいため）

ここまでの感想

さすがにこういったアーキテクチャのシステムは見たことがないので極端な例では…?とは思いつつ時代や場所によってはこういった設計のシステムも存在するのかもしれない。

CQRSとは

CQRSはBertrand Meyerが提唱した『Command and Query Separation Principle』にその起源を持つ。Wikipediaではこの原則を次のように説明している。

It states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both.

Command–query separation - Wikipedia より引用

とあり、すべてのメソッドはCommandかQueryのいずれかであるべきであり、両方を兼ねるべきではないと説明されている。

これに対し、Martin Fowlerは以下のようにPopのような操作はCommandでありQueryでもあり、必ずしも上記の原則を厳密に守らなくてもいいのではないか、ということを述べている。

Meyer likes to use command-query separation absolutely, but there are exceptions. Popping a stack is a good example of a modifier that modifies state. Meyer correctly says that you can avoid having this method, but it is a useful idiom. So I prefer to follow this principle when I can, but I’m prepared to break it to get my pop. (Fowler)

CQRS Documents by Greg Young P17より引用

ここまでの感想

実際にWebサービスを開発していてもたとえばユーザー作成メソッドが作成したユーザーのIDを返すような処理は普通に書くし、自分もどちらかというと定義ほどは厳密に運用しなくても十分恩恵を受けられるのではないかという立場。

“A Stereotypical Architecture"にCQRSを導入する

“A Stereotypical Architecture"として最初に紹介されたアーキテクチャでは、ドメインモデルがCommandとQueryの両方に使用されていた。このアプリケーションにCQRSを適用するとQuery側とCommand側はそれぞれ次のようになる。

Query

Query処理側にはデータ取得のためのメソッドのみが含まれる。

元のアーキテクチャではドメインモデルを生成し、それをDTOにマッピングしたうえでクライアントに返却していた。多くの場合でドメインモデルとDTOは異なるモデルであるため、以下のような課題があるがこれがCQRSの適用によって解決される。

複数集約から1つのDTOを生成する場合、複数回DBにアクセスする必要がありパフォーマンスが低下する。また、集約の境界が曖昧になる。
ドメイン層にQueryの責務が多く含まれている（e.g. repositoryのinterfaceにQuery系のメソッドが多く含まれ、ページングやソート情報が含まれている）

After CQRS has been applied there is a natural boundary. Separate paths have been made explicit. It makes a lot of sense now to not use the domain to project DTOs. Instead it is possible to introduce a new way of projecting DTOs.

CQRS Documents by Greg Young P20より引用

とあるように、CQRSを適用することでCommandとQueryの処理経路が明確に分離される。この段階ではドメインモデルをDTOの生成に使用しない方が合理的である。

その代わりに"Thin Read Layer"という方法でDTOを生成することができる。

CQRS Documents by Greg Young P21より引用

この層はDBから直接データを読み取り（ドメインモデルを迂回し）DTOを生成する。

こうすることで、ドメイン層からQueryの責務を切り離すことができ、ドメイン層の純度を上げることができる。

Command

CQRSを適用するとCommand側のアーキテクチャは以下のようになる。

CQRS Documents by Greg Young P22より引用

元のアーキテクチャでは書き込み系の処理をする際もDTOをクライアントから受け取っていたが、CQRS適用後はデータ中心ではなく振る舞い中心の契約を採用している点と読み取り処理が分離されている点が大きな違い。（元のアーキテクチャでは書き込み時にクライアントからDTOを渡していたが、ここではメッセージが渡されるようになっている）

また、元のアーキテクチャでドメイン層に存在していた次のような課題が解決されている。

リポジトリに大量の読み取りメソッドが存在する
DTO構築のためにドメインオブジェクトの内部状態を公開するゲッターメソッドが存在する
DTO構築のために複数の集約オブジェクトをそれぞれ読み込むことで、非効率なクエリが実行される

ドメインイベント、イベントソーシング

本文にはドメインイベント、イベントソーシングについても記載があり読んだがここでは割愛。

ここまでの感想

ドメイン層からQuery系の責務を切り離すことでメンテナビリティが向上する、というのが自分が（直近）CQRSに興味を持っていた一番の理由だったのでそうだよなーと思いながら読んだ。

また（書いてあるとおりだが）読み取り単位を必ずしもドメインモデル単位にする必要がないためパフォーマンスの最適化が行いやすい点も大きなメリットだといえそう。

結局CommandとQueryはまったく別の責務なことが多いので両者を分離することでメリットを得られるケースは多そう。

作業習慣の違い

CQRS Documentsを読むまでは意識していなかったが、CQRSを採用することで

ドメイン層
リードモデル
クライアント

の3つの要素に分解して作業を進めることができるため、プロジェクトに関わる開発者数をより効果的に増やすことができる。（サーバーとクライアントの作業分担をできるのはCQRSかどうかにかかわらないが、重要なのは1つのサーバーアプリケーションを2並列で安全に進めやすいという点だろう。）

また、開発者には次のような観点の差異が存在する。

技術的熟練度
ビジネスドメインに関する知識
コスト
ソフトスキル

ドメイン層の実装には4つすべての項目が秀でた人材が最適である一方、リードモデルの実装にはそれらの開発者要件は必ずしも当てはまるとは限らない。

ここまでの感想

開発効率の観点は持ってなかったが、たしかにCQRSを採用することで（1つのアプリケーションが2つのモジュールに分離されるので）コンフリクトせずに開発を進めやすそう。（モジュール設計はプロジェクトによるので厳密には2つのモジュールとは限らないが）

感想

事前のイメージ通り、CQRSを適用することで開発効率を高められそうなイメージが持てた。

CQRS Documents内でも触れられていたが、結局CQRSにしろイベントソーシングにしろ一定のオーバーヘッドはあるので、システムやビジネスの課題や要件、今後の見通しを元に必要性を検討するのが（いつだって）重要そう。

というのはありつつ、ドメイン層のメンテナビリティを高めるためにCQRSを採用するのはかなり有効な選択肢の1つだとも感じているので、ひとまず個人のプロジェクトで検証してみたいと思う。

もちろんアプリケーションの状況にもよるが…。repositoryのRead系メソッドの返り値がドメインモデルと一致しないケースが多くなるような場合では特にCQRSのメリットが効果を発揮しやすいような気がしている。状況にかかわらずCQRSをやったほうがいいのかどうかはまだあまりわかっていない。ちなみにここでのCQRSは基本的には同一DBでCのアプリケーションコードとQのアプリケーションコードが分離されている、くらいの方法をざっくり想定して書いている。（CとQでDBを分けるパターンは流石にtoo muchなケースが多そうなので） ↩︎
厳密にこのドキュメントが原典であることを確認したわけではない。正確な情報をお持ちの方がいたら教えて下さい。 ↩︎

『Tidy First?』を読んだ

Sat, 04 Oct 2025 08:21:10 +0000

『Tidy First?』を読んだ。

勉強になったところをまとめる。

「整頓」という概念

整頓はリファクタリングのサブセットだ。整頓は可愛くてふわふわした小さなリファクタリングなので、誰も嫌いになれないはずだ。

リファクタリングほど大掛かりなものではなく、数十分でできるような小さな改善を本書では「整頓」と呼んでいる。

具体的にはコードコメントを追加したり適切な位置に空行を配置したり適切な変数名に変更したりすることなどを指している。

この「整頓」という概念を知ることができたのが本書を読んで得られた最大の収穫だった。今までそのような行為に名前をつけたことがなかったが名前をつけることで使い所や意義が明確になり意識的に実践できるようになりそう。

なお本書では「整頓」と「振る舞いの変更」の順番やタイミング、粒度や意義について様々な角度から書かれているので気になる方はぜひ手にとってみてほしい。

第11章ステートメントを小分けにする

大きなコードのチャンクを読んでいると、「ああ、ここはこれをしていて、あそこであれをしているのか」とわかる。そのあいだに空行を入れよう。

長めの関数を読むとき、空行がまったくないことは少ないが空行の位置を改善できそうだと感じることがたまにある。

処理の塊ごとに適切に改行されているだけでそこそこ可読性が上がる実感があるのでやってみようと思う。（空行の追加/削除のみのPRであればレビュワーの負担もかなり少ないはず）

第13章ひとかたまり

細かく分割されているがゆえに、かえって理解を妨げているようなコードに出会うことはないだろうか。

超巨大な関数はテストしづらく可読性も低いので避けたいが、逆にすべての処理を関数として切り出してしまうと毎回定義ジャンプしないと処理の内容がわからないのでかえって読みづらくなってしまう。

テストが書きやすい程度に細かくかつ可読性が落ちない程度には大きく関数を切り出すのがよさそうで、いい塩梅を探るには複数のパターンを実際に書いてみて読みやすいかどうかを判断するのがよさそう。（実際に複数パターンを書いてみると意外とすぐに書けることが多いし、しかも実際に書いてみると事前の想定とは印象が違うことが多いように思う）

小さな部品に分けようとするのは、コードを少しずつ理解できるようにしたいからだ。だが、ときには、このプロセスが間違った方向に進むことがある。小さな部品のやりとりの仕方によっては、コードが理解しにくくなるのだ。明確さを取り戻すには、まずはコードを1箇所に集めて、それから改めて、簡単に理解できる部品を抽出する。

1000行の関数でこれをやるとさすがに辛そうだが、100行前後くらいであればひとまず1つにまとめてから再構成するのはたしかに良さそう。

第14章説明コメント

コードを読んでいて「なるほど、それでこうなっているのか」と声が出ることがある。これは貴重な瞬間だ。記録しよう。

コードリーディングの結果、必要なコメントが欠けていることに気づくことがある。

そういった場面でこれまであまりPRを作ったりはしてこなかったが、説明コメントの追加も立派な整頓であり将来の読者（当然将来の自分を含む）の時間を節約することに繋がるのでやっていきたい。

説明コメントの追加PRはレビュワーの負荷が少ない割にレビュイーとレビュワーのコード理解を深められる点で比較的コスパの良い取り組みな気がした。（正確な説明コメントを書くための調査が大変、とかはあるかもだが）

第19章リズム

1つの整頓にかける時間はここでは1時間くらいまでが許容範囲とされており、それを大幅に超過するようであれば変更の単位が大きすぎる兆候らしい。

こんな話を聞いたことはないだろうか。ある大学がたくさんの建物を造った。計画者は、それを結ぶ歩道をどこに造るか考えていた。だが、そこで経験にもとづいて注意深く推測するのではなく、建物のあいだのエリアに芝生を植えたのだ。数か月後、学生の歩いた跡によって芝生に道ができた。計画者は芝生がなくなったところを舗装した。

コードにおいて、振る舞いの変更は一部に集中する傾向にある。パレートの法則にあるように、80%の変更は20%のファイルで起こる。

（計画者天才すぎワロタ…）

変更の前に整頓することを続けていくと頻繁に変更される20%のコードがどんどん綺麗になっていく、ということを言っているのだと解釈した。

そうした取り組みを続けていくとコードの大部分は手直ししてないにもかかわらず整頓していないコードに出会うことは稀になる。逆に言うと仮にコードの50%を頑張って綺麗にしたところで、その50%に変更がまったく入らないのであれば投資対効果が高いとはいえないかもしれない。（当然、コード全体が複雑に絡み合っていて一部だけ再設計することが難しい場合や全体的に変更しないと一貫性がなくなる場合などはその限りではないと思う）

なのでコードを修正する際は単純にある時点のコードベースだけを見てコード品質に改善点が見つかったというだけの理由で修正する、というよりは修正すべき合理的な理由（e.g. 内部品質が課題で問題が起きている、よく変更が入る箇所が変更しづらくなっているなど）がある箇所から対応していくのがよさそう。

第21章先に整頓、あとに整頓、改めて整頓、整頓しない

整頓を変更の前にやるか、あとにやるか、将来時間がとれたときにやるか、あるいはまったくやらないかについて論じた章。

章のまとめにもあるように結局はビジネスにとって合理的なタイミングでやるのがよい、ということなのだと思った。（言葉にするとそれはそうという感じではあるが）

「改めて整頓する」と「あとに整頓する」の区別はあまり考えたことがなかったが、整頓が完了するまでの必要工数が大きいケース以外は「あとに整頓する」に寄せるのが良さそうに感じた。

第25章明日の1ドルより今日の1ドル

お金を生む振る舞いの変更を今すぐ実装して、あとから整頓できるなら、すぐにお金が手に入り、あとでお金を使うことになる(前述のとおり、ときには先に整頓してから振る舞いを変更するほうが整頓せずに変更するよりも安価なこともある。そんな場合は常に先に整頓する)。

ビジネス的なメリットがあるならば整頓を後回しにすることが合理的になるのは十分にありえる。(e.g. 12/1までにリリースできれば大企業A社の受注に繋がるが、それを超過してしまうと競合他社と契約されてしまい、A社と契約できるチャンスが消滅してしまう)

逆に、先に整頓したほうが変更が楽になるならそうする。コードベースへの理解、ビジネスへの関心と理解（デッドラインは最終的なものなのか、調整可能なのか）、一定の設計スキルなどがあるとこの判断の練度を上げることに繋がりそう。

第26章オプション

「次にどのような振る舞いを実装できるか」は、実装する前から、それ自体に価値がある。

これはあまり考えたことがなかった。「プログラムの変更容易性は将来の実装工数を削減するために重要である」というアイディアと本質的には近いことを言ってそうだが、「価値」という切り口で捉え直すとたしかに変更容易性は価値と等価ともいえそう。

（これが最重要なのだが）価値予測の不確実性が高いほど、オプションの価値は高い（今すぐ実装するのと比べて）。

価値予測の不確実性と変更容易性の価値についてもあまり考えたことがなかったが納得感があった。たとえばよくあるSaaSモデルのプロダクトであれば探索しながら市場の反応を見たり変化に対応したりすることが必要で、そのためには変更容易性が必要なのでその価値がより高まる、ということだと理解した。

第32章凝集

凝集性が低いモジュールの改善方法についての章だが、どちらかというと章の後半に書かれていた下記の記述が参考になった。

次の人のために少しだけコードを整頓しておこう。全員がこのボーイスカウトルール(「来たときよりも美しく」)に従えば、そのうちにより扱いやすいコードになっていくだろう。

これまではボーイスカウトルールというと「触ったコードの負債をできるだけリファクタリングして綺麗にすべし」のような考え方だと認識していた（これ自体は間違いではないと思う）。

本格的なリファクタリングまではいかなくとも、本書で「整頓」として紹介されている「コードコメントの追加」や「空行の調整」なども十分ボーイスカウト的な行為なのだなと考え直して少しハードルが下がる感覚を得た。

第33章結論

本書のタイトルにもなっている、どんなときに先に整頓すべきかについてのまとめの章。

以下の4つの観点で整理して決断するとよい、と書かれている。次に判断に迷った際には参考にしてみたい。

コスト
収益
結合
凝集

まとめ

164ページと全体がコンパクトにまとまっているのと、簡潔に書かれている（かつ、翻訳もとても読みやすい）ので短時間で読みやすかった。

「整頓」 という概念を知れたのが最大の収穫だった。今後は意識的に実践していきたいと思う。

次回作の構想もあるようなので楽しみ。

『ちょうぜつソフトウェア設計入門 PHPで理解するオブジェクト指向の活用』を読んだ

Sat, 15 Jul 2023 15:00:00 +0000

田中ひさてるさんの『ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用』が話題になっていたので読んでみた。

全体を通して平易な日本語で書かれていたのとコード例が豊富だったので理解しやすくてよかった。

以下学びを簡単にまとめていく。

第2章パッケージ原則

より変更に強いパッケージ設計にするために注意すべき点として

パッケージの凝集性を高める
より安定度が高い(=抽象度が高い)パッケージに依存する

などがある。

また、凝集性の低さを表すシグナルとしてそのパッケージが変更される理由が複数あること・1つの変更の際に変更対象となるパッケージが複数あること(それぞれ同じ?)が挙げられる。

「抽象」については以下のように説明されていた。

抽象クラスやインターフェイスなど実装詳細を自身から排除したもの

上記のような詳細を持たないものだけに依存するロジック

固有の業務にも特定技術にも関係しない時刻や配列などの汎用概念とその操作

プログラミング言語そのものや言語標準ライブラリと同等レベルの業界標準

第3章オブジェクト指向

いい抽象を見つけるには

具体的な例を分析してそれらから抽象を見つけることで期待値の高い抽象を発見できる。

逆に先にひとりよがりの哲学をこねくり回して現実をかえりみない抽象化を先行させた場合は、役に立たない概念に縛られる無駄が起きやすくなる。（ペットショップのシステムなのに「Catには野良猫もいるかもしれない。必ずしもPetではないかも……」みたいなことを考えてしまうのは明らかに無駄）（抽象化においてもYAGNIが重要っぽい）

無限の可能性に向かって発散してしまわず、いかに可能性を削ぎ落として最小サイズで実際に起こりうるバリエーションをカバーできるかが汎化のポイント。

そういう意味でもドメインやビジネスの状況を理解しておくことはプロダクトの将来を考慮しながら設計するために必要なんだろうなと思った。

「多」態性がなくても役立つ

抽象と具象は必ずしも1対多の関係である必要はない。

具象と抽象に分けておくことで先に大枠を安定させることができるため、設計の見通しがつきやすくなる。

また、具象の数が複数になったときに対応しやすいというメリットもある。

これまで「抽象と具象が1対1対応なケースはわざわざDIする必要はないのでは」と思っていたが上記のメリットがあるので積極的にDIしていこうと思った。

第5章オブジェクト指向原則 SOLID

5-2 単一責任原則(Single Responsibility Principle(SRP))

クラスと責務は1対1対応すべき、という指針。

単一の責務のみつけかた

クラスの利用者がどんなときに別のクラスや新しいバージョンに交換したいと思うかを想像する。

実際に起こりそうな交換要求への想像が責務(= クラスのカバー範囲)を見極めるヒントになる。

たとえば記事クラスが存在し記事の入稿および購読というユースケースがある例では以下のように考えることができる。

ニュース記事を書く人の事情が変わったけれど、購読ユーザーには従来どおりのサービスを提供したい。逆に、入稿はそのまま、購読ユーザーへのサービスを拡張したい。そんなニーズが起きるのは容易に想像できます。入稿と購読のそれぞれを互いに影響を与えない独立したクラスとしておき、いつでも気兼ねなく別の実装に交換できる単位としておく方が、後で便利に決まっています。なので、ニュース記事管理の場合は、「入稿」と「購読」が、それぞれひとつの責務になります。

5-3 開放閉鎖原則(Open Close Principle)

拡張に対してオープン、変更にたいしてクローズドであるべき、という指針。

これは書籍内で紹介されていたコード例がわかりやすかった。

あとはどこが変化する仕様なのかを考えるために一度要件を抽象化してみる方法が紹介されていた。こちらもコード例が示されていたのでイメージが湧きやすかった。

第7章依存性注入

オブジェクトが使う機能の実体を得る際その解決を自力で行わず、常に外部から与えるようにすべき、という設計方針。

依存性注入を行うメリットの1つは生成の責務と使用の責務を分けられる点がある。

また、テスト容易性とDIについては以下のような記述があった。

単体テストしやすいクラスであることと、DI可能なクラスであるということには、正の相関があります。DIを単に「単体テストのためにやること」といった目的観で考えるのは視野狭窄ではあるのですが、単体テストがアーキテクチャへの気づきの手段として、とても有用なのは間違いありません。

テストが書きずらかったら設計を疑ってみるのも1つの手かもしれない。

まとめ

よく聞くSOLID原則もやっとちゃんと理解できたし依存性注入に対する理解も深まったので今後に活かしていきたい。

デザインパターンをひととおり眺めた感想

Wed, 01 Feb 2023 16:15:48 +0000

ずっと気になってはいたが2つ~3つくらいしか知らなかったデザインパターンをやっと勉強する気になったのでこのサイトを一通り眺めてみた。

デザインパターン

デザインパターンは、ソフトウェア設計でよく起きる問題に対する典型的な解決方法です。これらは、事前に用意された、問題解決のための設計図で、適宜変更して、自分のコードにおける特定の設計上の問題の解決に使えます。

https://refactoring.guru/ja/design-patterns

こちらのサイトは平易な文章とわかりやすい例で説明がされていて、各言語でのサンプルコードも載せてくれていたのでかなりサクサクと理解できてとてもよかった。(各パターンをC#, C++, Go, Java, php, Python, Ruby, Rust, Swift, TypeScriptで実装した例が紹介されていた)(すごい)

自分のデザインパターンとの向き合い方について

周りのエンジニアにデザインパターンについて聞くと、

すべてのパターンが今も有用かと言われるとそうでもないかも
よくある設計パターンの共通言語として知っておくとコミュニケーションの効率があがってよい
暗記までする必要はなくて設計のときの参考程度にするとよさそう

みたいなことを言っているのをよく聞くのですべてを自分のものにするというよりは軽く雰囲気を理解するくらいのテンションでサイトを眺めてみた。

感想

一通り眺めてみて、以下のようなことが重要なんだろうなと感じた。

interfaceをうまく使って抽象に依存する
データと振る舞いを分離する
依存の方向に気を付ける

いろんなところで言われていることだが、やはり責務の分離や単一責任の法則を意識することで変更しやすいコードにしていくことがよりよい設計に繋がることを再確認できた。

いいコードを書けるようになるにはこれらのことを意識しながら実際にコードを書いて実践していくことが重要だと思うのでたくさん試行錯誤していい感じのコード書き力を身につけていきたい。(とても経験豊富な先輩エンジニアも結局自分でサービスを運用して設計の失敗の痛みを感じるのが一番成長できる、というようなことを言っていた)

設計関連だと良いコード/悪いコードで学ぶ設計入門 ―保守しやすい成長し続けるコードの書き方とか Clean Architecture とかも気になってるので読みたい。

設計 on blog.kyu08.com

『CQRS Documents by Greg Young』を読んだ

CQRSに興味を持ったきっかけ

“A Stereotypical Architecture”: 典型的なアーキテクチャ

ここまでの感想

CQRSとは

ここまでの感想

“A Stereotypical Architecture"にCQRSを導入する

Query

Command

ドメインイベント、イベントソーシング

ここまでの感想

作業習慣の違い

ここまでの感想

感想

『Tidy First?』を読んだ

「整頓」という概念

第11章 ステートメントを小分けにする

第13章 ひとかたまり

第14章 説明コメント

第19章 リズム

第21章 先に整頓、あとに整頓、改めて整頓、整頓しない

第25章 明日の1ドルより今日の1ドル

第26章 オプション

第32章 凝集

第33章 結論

まとめ

『ちょうぜつソフトウェア設計入門 PHPで理解するオブジェクト指向の活用』を読んだ

第2章 パッケージ原則

第3章 オブジェクト指向

いい抽象を見つけるには

「多」態性がなくても役立つ

第5章 オブジェクト指向原則 SOLID

5-2 単一責任原則(Single Responsibility Principle(SRP))

単一の責務のみつけかた

5-3 開放閉鎖原則(Open Close Principle)

第7章 依存性注入

まとめ

デザインパターンをひととおり眺めた感想

自分のデザインパターンとの向き合い方について

感想

第11章ステートメントを小分けにする

第13章ひとかたまり

第14章説明コメント

第19章リズム

第21章先に整頓、あとに整頓、改めて整頓、整頓しない

第25章明日の1ドルより今日の1ドル

第26章オプション

第32章凝集

第33章結論

第2章パッケージ原則

第3章オブジェクト指向

第5章オブジェクト指向原則 SOLID

第7章依存性注入