クリーンアーキテクチャにおける詳細や些細なものを説明していく
データベース
データベースは詳細を提供し、下位レベルの仕組み。アーキテクチャは下位レベルの仕組みに汚染されることは許したくない。
view のような上位レベルの概念にとって下位レベルが何なのかは関係ないからである。
また、データベースはディスクと RAM の間でデータを移動する仕組みに過ぎない
モデル
モデルはビジネスロジックの置き場
https://qiita.com/takasek/items/70ab5a61756ee620aee6
→ これはプラットフォームや OS による差分が発生しない部分
エンティティ
正直、話す文脈によって変わるので理解するのかなり厳しい
- 表でいうところの行やレコードに対しての機能を定義する(フレームワーク)
- O/R マッピング
- 一意な識別子で特定できるもの(DDD)
- 指定席はエンティティ、自由席は値オブジェクト
- 3 分でわかる値オブジェクト
- もはやモデルでは？と思う
- コンピュータシステム内部にあるオブジェクト、最重要のデータとルールを含んだもの(クリーンアーキテクチャ)
- DDD のような分類はされておらず、エンティティも値オブジェクトもどちらも含むような意味合いで捉えられている
エンティティとは！ ~ であるという問いに答えることは不可能(文脈で変わるから)。という結論に落ち着いたが、個々のレコードを指していて、ビジネスルールを含むものぐらいの認識で良いのではないかと思う。
参考: お前らが Model と呼ぶアレをなんと呼ぶべきか。近辺の用語(Entity とか VO とか DTO とか)について整理しつつ考える
- せっかくなので、以前使っていた CakePHP3 における Entity の使い方を乗せておく
namespace App\Model\Entity;
use Cake\ORM\Entity;
use Cake\Auth\DefaultPasswordHasher;
class User extends Entity
{
// パスワードをハッシュ化
protected function _setPasswordHash($password)
{
return (new DefaultPasswordHasher)->hash($password);
}
}
ウェブ
ウェブというか GUI は詳細である
見た目はビジネスロジックとは関係がないからである
ただし、UI とアプリケーションの間の境界抽象化できる(decorator)
フレームワーク
- フレームワークの作者はあなたのプロダクトのために開発しない
- フレームワークの進む方向が望む道から外れることがある
- 他の優れたフレームワーク を見つけると乗り換えたくなる
フレームワークはアーキテクチャの内側に入ってこようとするが、これを受け入れてしまうと上記の問題が起きた時に取り外すことがとても難しくなってしまう
これを解決するためには、外側にあるものとして扱い依存性のルールを守るようにする
つまり、安定度の高いものに向かうようにする
まとめ
クリーンアーキテクチャは境界線を明確に意識することが大事だが、その中でも詳細に値する DB や GUI、フレームワークは出来るだけ他からの依存をなくすように設計できると良い。と言う結論に至った。