eno314のアウトプットリポジトリ

技術書の読書ログや動画、記事等の閲覧ログを書き溜めていきます

「Clean Code アジャイルソフトウェア達人の技」読書ログ 第11章

11章 システム

要約

システムを「使う」ことと「構築」することを分離する

  • オブジェクトの生成や依存関係の解決等の、アプリケーションの開始処理は、それ1つで1つの関心事
  • モジュール化して、通常のランタイム処理から切り離し、それが主要な依存関係を解決するための包括的で整合性のとれた手順となるようにすべき
  • 手段
    • mainモジュールに構築処理をまとめる
    • アプリケーション内でオブジェクト生成が必要な場合はAbstractFactoryパターンを使う(Factoryの実装クラスはmain側)
    • DI

システムはインクリメンタルに成長させる

  • 最初から正しいシステムは理想論。ストーリーを実装しながら、システムをリファクタリング・拡張させる
  • 適切に関心事を分離して保守していけば、アーキテクチャもインクリメンタルに成長させることができる

横断的な関心事には、アスペクト指向プログラミング(AOP)のアプローチを行う

  • 永続化のような横断的関心事はモジュール構造を取ることが難しい。AOPは横断的関心事に対してモジュール構造を取り戻すための一般的なアプローチ
  • 永続化を例にとると、どのオブジェクト、属性が永続化されるかを宣言するだけで、使用してる永続化フレームワークに永続化の作業が移譲される
  • AOPフレームワークによって、振る舞いに対する変更が、非進入的(対象に対する手作業の変更が不要)に行われる

アーキテクチャをテスト可能にしてインクリメンタルに成長させる

その他のTIPS

  • モジュール化と関心事の分離させることで、意思決定を最適化する。決定は、それが手遅れとなる直前まで延期することで、最善の情報に裏付けられた決断を行うことが可能
  • 標準となっている技術も自分たちのニーズにあっているとは限らないので、使用の際は気をつける
  • ドメイン特化言語を使うことで、高いレベルの方針から、低いレベルの詳細までの、あらゆる抽象レベルと、アプリケーション内のあらゆるドメインPOJOで表現することが可能になる

感想

ドメインロジックがアーキテクチャの関心事からコードレベルで分離されると、アーキテクチャのテスト実行が可能になる」っていう部分があまりしっくりきていない。ドメインを除いたアーキテクチャ部分だけのテストを書けばいいのか、ドメインを含めたテストを書けばいいのか、どっちなんだろう。。