Clean Architecture - seiyab/wiki Wiki

Clean Architecture

Book

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Notes

第II部 構成要素から始めよ

  • 第5章 オブジェクト指向プログラミング
    • 依存関係逆転
      • 「ビジネスルールは、UIやデータベースとは独立してデプロイできる」
        • データベースと独立してビジネスルールをデプロイしたいケースは現実的によくあるのか？（UIはよくある）
        • 「データベース」としてテーブルのスキーマ等も含むならビジネスルールの変更と共にデータベースへの変更もデプロイしたい場合が多いのではないか
        • そもそもデプロイを高価に見積りすぎではないか。時代と共にデプロイのコストの考え方が変わっている？
      • 「システムにあるモジュールを個別にデプロイできるなら、別々のチームが個別に開発できる。」
        • これもやはりビジネスルールを書くエンジニアがテーブルのスキーマを書くほうがよいのではないか

第III部 設計の原則

  • 第7章 SRP: 単一責任の原則
    • 「モジュールはたったひとつのアクターに対して責任を負うべきである」
      • すべてのモジュールにこれを当てはめるのは不可能ではないか
    • 「変更を望む人たちをひとまとめにしたグループとして扱いたい。」
      • このように考えるなら変更する理由とアクターはby definitionで同じになり、意味のない言い換えになってないか
    • 「一番わかりやすいのは、データを関数から切り離すというものだろう。」
      • EmployeeDataは依然複数のアクターに責務をもっているようだが、何が解決したというのか
  • 第10章 ISP: インターフェイス分離の原則
    • 「再コンパイルや再デプロイを強制されるので明らかに有害」
      • 再コンパイルや再デプロイは「明らかに有害」というほど高価ではなくなったのではないか

第IV部 コンポーネントの原則

  • 第14章 コンポーネントの結合
    • トップダウンの設計
      • 「コンポーネントの依存構造は、システムの論理設計に合わせて育てていくものだ」
        • 依存構造を絶対的に制御するため依存関係逆転を推奨する記述が多いが、そもそも達成したい依存構造はシステムの論理設計に合わせて育てていく
        • 例の丸い図より、システムの論理設計が優先されると解釈していいはず
    • 安定依存の原則（SDP）
      • わかりやすい指針を示しており、目立った欠陥も思いつかないが安定度・抽象度をトラックする仕組みはさほど普及していないのか

第V部 アーキテクチャ

  • 第15章 アーキテクチャとは？
    • 選択肢を残しておく
      • 「開発の初期段階でデータベースシステムを選択する必要はない」
        • データベースの種類を何も想定しない場合、不可能な方針が出来上がってしまわないか？
          • 全く不可能な方針を除けば、論理設計のあとにとりうる選択肢から適切なものを選べるに越したことはない点は同意
  • 第16章 独立性

Related articles