Clean Architecture

2020-09-10 読了

ロバート・C. マーチン

毎日 15 分読んで、読み切る。

21. 叫ぶアーキテクチャ

  • 優れたアーキテクチャは usecase を中心

    • これを最初に考えて、詳細(DB/Framework)はあとから考える
  • Web は I/O である
  • アーキテクチャがシステムそのものについて、情報を与える。Framework についてではない。

22. Clean Architecture

  • ヘキサゴナルアーキテクチャ
  • DCI アーキテクチャ
  • BCE

「関心事の分離」が目的

  • フレームワークの非依存
  • テスト可能
  • UI 非依存
  • データベース非依存
  • 外部エージェント非依存

エンティティ

  • ビジネスロジック

ユースケース

  • アプリケーション固有ロジック

インターフェースアダプター

  • 便利なフォーマットに変換する
  • Presenter, View, Controller (Model = Controller -> Usecase -> Presenter)

フレームワークとドライバ

  • 一番外側の円
  • 最小のコードになるように、グルーコードぐらい

境界線を超えるデータは単純なオブジェクトであるべき、DB Framework の行構造のデータ構造を利用して、依存性のルールに違反してしまう可能性もあるから、注意が必要

23. プレゼンターと Humble Object

View は Humble Object である。Presenter はテスト可能なコンポーネントでそれらを分離する。

24. 部分的な境界

  • Strategy Pattern
  • Facade

YAGNI (You Aren't Going to Need It)

25. レイヤーと境界

26. メインコンポーネント

  • Clean Architecture の一番外側の円
  • 上位レベルのシステムのためにすべて読み込む
  • 開発用、テスト用、本番用に Main を用意することもできる

27. サービス:あらゆる存在

マイクロサービスアーキテクチャを採用していても、データや振る舞いが結びついている限り、開発・デプロイ・運用には調整が必要。

VI 部 詳細

30. データベースは詳細

  • データはどのような構造をもつかは重要だが
  • データベースはデータモデルではない
  • ディスクと RAM との間のデータを移動する仕組みにすぎない
  • もし、ディスクがなくなって RAM だけになったら、リンクリスト、ツリー、キュー、スタックなどを使ってデータの管理をするだろう
  • 今だって、データベースから取得したデータはこのような形で使っている

31. ウェブは詳細

  • ウェブは入力デバイスの一種

32. フレームワークは詳細

  • フレームワークとは一歩的に結婚しない
  • 使うことは良いがちゃんとそのリスクを考えた上で使用する
  • 牛一頭を購入する以外にもミルクを得る手段はあるはずだ

33. 事例:動画販売サイト

34. 書き残したこと

  • レイヤーによるパッケージング
  • 機能によるパッケージング
  • ポートとアダプター

    • 内側に含まれるドメインの概念
    • 外側には外部の世界とのインタラクション(UI、DB、サードパーティ)
    • ゆるいレイアードアーキテクチャ
    • 同じ層のコンポーネントを参照してしまう
    • 完全に違反はしてないが、できるだけ避けたいので、ツールで解決する(NDepend, Structure101, Checkstyle など)
2019 © Kazushi Kawamura.