Clean Architecture
The goal of architecture is to find the best way to separate the interests of each component.
基本的な考え方。これらは最低限表現する必要がある。
重要なものを重要でないものか保護したい
言い換えると
変わらないものを変わりやすいものから守りたい
変更の影響範囲をなるべく小さくしたい
なにかを変更するときに、変えたくないものまで変えないといけない状況を防ぎたい
このためには、依存関係を適切に設計する必要がある。依存関係の制御。
A が B に依存しているとき、B が変わると A も変えなければならない
分離
コンポーネントにわける
分類
分けたコンポーネントの変更したくない度合いで分類する
クリーンアーキテクチャ的には、円のどの部分に位置するか
中から外には依存してはいけない
どう表現するか?その手法の一つとしての DDD
このあたりのレイヤーが必要
domain
usecase
presentation
repository
実装に依存せず、interface に依存する
実装の詳細
バリデーション
domain レイヤーは当然バリデーションが必要
domain のルールを presentation でもバリデートする場合、domain で実装しているロジックを直接使えるようにするとよいのでは?そのような仕組みが必要。
型変換
presentation レイヤーの型と domain レイヤーの型をどう変換するか
例えばこういう仕組みをもっているフレームワークもある
ドメインオブジェクトが、仕様として正しいかどうかを確認する方法を提供する必要がある?
あるいは、正しくないドメインオブジェクトを生成できないようにする仕組みが必要
Repository が必要な理由
ビジネスロジックが DB レイヤー依存しないため
ビジネスロジック側で、DB に行う操作を repository として定義する
DB レイヤーが repository interface を実装する。ビジネスロジックはそれを呼び出す。
制御の流れはビジネスロジック -> DB だが、DB レイヤーがビズネスロジックに依存している。依存性逆転。
Repositoty パターンにおける命名
Create 系
直接 DB が呼ばれるのであれば、Add よりも Save のほうがよいか?
Save の意味的に 作成と更新の両方を含んでしまいそう?
Save or (Create and Update )
Read 系
直接 DB が呼ばれるのであれば、Get よりも Find のほうがよいか?
Delete 系
直接 DB が呼ばれるのであれば Remove よりも Delete が良さそう