Clean Architecture

毎日 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 など）