CleanArchitectureの話
記事を書くのに間が空き過ぎてしまった・・・
最近天則に復帰したりVLORANTが楽しかったりで忙しいです
転職したいならその時間を勉強にあてろ
CleanArchitectureの勉強はぶっちゃけ手間取りました
DDDもかじりながらボブおじのブログを読んだので・・・
あと原文をそのまま理解しようとするのは難易度が高い
そもそもCleanArchitecture自体がちょっと難しい・・・（個人差があります）
正直なところ記事にするけど内容の正確性に自信がない
まさかり募集
CleanArchitectureを一言でまとめると
「抽象度でレイヤー分けして、依存性を排除したアーキテクチャ」
具体的なモノ（抽象度が低いもの = UI, DB, etc...）は変更されやすいので
そこは一番いじりやすくしようぜ！みたいなニュアンスだと思ってます
ここからは和訳もかねて書いてく
みんな大好きなあの図。ボブおじのブログから引用
様々なアーキテクチャがあるが基本的に目的は同じであり
「ソフトウェアを機能ごとにレイヤー分けすることで関心の分離を行う」ことにある
フレームワークに依存しない
制限された状態でシステムに機能を落とし込む必要性が無くなるテスト可能
外部に依存しないのでテストができるUIに依存しない
DBに依存しない
外部から独立している。ビジネスルールは外部の状態を知らなくても良い
依存関係のルール
外側から内側に向けて依存する
内側はが外側の状態を知らなくても良い
エンティティ
不変なビジネスルールを記述
サービスの基幹部分（単一のアプリケーションであれば、アプリの仕様になる）
要はこれがなきゃサービスにならないレベルのもの（＝ドメインオブジェクト ）
ex.) twitterであれば「ユーザー」や「ツイート機能」などに当たる
外部の変更があった場合でも、変更される可能性が最も低い
ユースケース
エンティティに記述しないようなビジネスルールはこっちに記述する
ソフトウェアの仕様変更の影響を受ける
このレイヤーはエンティティへ影響を与えることは想定していない（無関心）
エンティティとのデータフローを調整
ユースケースの目的を達成できるようにエンティティへ指示する
インターフェースアダプター
エンティティやユースケースのデータを、DBなどで使える形に変換する
エンティティとユースケースはDBについては知らなくて良い
ようはぶっちゃけViewMode強化版みたいなとこ
フレームワークとドライバ
DB・UI・Webのフレームワーク
変更の多いところはここ
図について
あくまで例として４つのレイヤーにしただけで、増えることもある
仮に増えても依存性は外側から内側へなのは変わらない
内側へ向かうとソフトウェアはより抽象的になる
レイヤーの境界を超える
右下の図について説明
ユースケースと通信するコントローラーとプレゼンター
コントローラで始まりユースケースを内でデータを操作、プレゼンターで実行
普通は「依存性逆転の法則」を利用するんだとかなんだとか
直にやりとりすると依存性が高いので×
境界を超えるデータ
境界を越えてデータを渡す場合
常に内側の円に最も便利な形式で渡す
内側の円は外側の状態を意識しなくて良い！
個人的な感想
実装の仕方やモノによって、様々なデータの流れがあって複雑になりそう
抽象度が高い部分で、ロジックをどこに書くかというのが曖昧になりそう
別途ルールを作らないと、人によって書き方がバラバラになりそうかなー・・・？
ちょっとまだ理解がふわふわしてる
UIが一番上で、DBが一番下なアーキテクチャに馴染みがあるので理解するのに時間がかかった
