onemuri.space

詳細 -クリーンアーキテクチャ-


クリーンアーキテクチャにおける詳細些細なものを説明していく

データベース

データベースは詳細を提供し、下位レベルの仕組み。アーキテクチャは下位レベルの仕組みに汚染されることは許したくない。

view のような上位レベルの概念にとって下位レベルが何なのかは関係ないからである。

また、データベースはディスクと RAM の間でデータを移動する仕組みに過ぎない

モデル

モデルはビジネスロジックの置き場

https://qiita.com/takasek/items/70ab5a61756ee620aee6

→ これはプラットフォームや OS による差分が発生しない部分

エンティティ

正直、話す文脈によって変わるので理解するのかなり厳しい

  • 表でいうところの行やレコードに対しての機能を定義する(フレームワーク)
    • O/R マッピング
  • 一意な識別子で特定できるもの(DDD)
  • コンピュータシステム内部にあるオブジェクト、最重要のデータとルールを含んだもの(クリーンアーキテクチャ)
    • 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、フレームワークは出来るだけ他からの依存をなくすように設計できると良い。と言う結論に至った。

参考

Clean Architecture 達人に学ぶソフトウェアの構造と設計

自己紹介用画像

Riki Akagi

2019年からDeNAで働いています。GCP(CloudSQL・GAE・Cloud Function etc)とGoでAPI開発に勤んでいます。睡眠やエンジニアリングに関することに興味を持って過ごしているのでその情報を皆さんに共有していけたらなと思っています。

自己紹介の詳細