manners_maketh_man

TODO

• usecaseのWrapperのサンプルコード・記述がないのでつくる
• デバッグメニューの出し方を考える
  • FirebaseのユーザのホワイトリストをFirebase上から取ってこれるようにする

Overview

• 今現在遠藤がまとめた、FlutterPJのアーキテクチャです
• 実装サンプルなので全く動きません

考え方の方針

• DDDの思想
  • レイヤードアーキテクチャーになっていること
  • ドメインモデルがまとまっていること
• シンプルさの必要性
  • http://eed3si9n.com/ja/simplicity-matters/
  • 処理は独立していて、お互いにインタリーブ（処理が交差する）しないこと
    • ただし、ドメインはインタリーブすることがある
    • 例）車で例えると
      • タイヤとエンジンが、それぞれ相互にドメインを参照するのはNG
        • 現実に即していない（エンジンはシャフトを通して動力をタイヤに伝える）相互作用は表現してはいけない
      • 燃費を図るというusecaseにおいて、エンジンとタイヤはインタリーブしていい
  • オブジェクト指向ではなく、基本的には関数を呼び出して処理する
• Linux哲学に準じて、ひとつの処理がひとつのことを実行するよう構成する
  • レイヤードアーキテクチャ・ドメインモデルで構成することで、独立性を担保する
• 柔軟に変更可能だが、レイヤードアーキテクチャのルールは守ること
  • src/配下は単独でビルドできること
  • viewのtemplateとcomponentは独立してビルドが通ること

ディレクトリ構成

• 下記の通りに構成される
  • 画面
    • view/
  • ユーザアクション
    • view/
  • データ取得・加工の処理
    • src/
• 「Viewのボタン、イベント」 = Controllerとみなし、src/1_usecaseの処理を呼び出す
• Stateは画面間で共有せず、基本的にはページ遷移時にメモリやパラメータ上で渡す
• 名称の数字は依存関係を表す
  • 基本的に1 -> 2 -> 3の順に処理を呼び出す

ロジック部

1_usecase

• Pageから呼び出される処理のエントリーポイント
  • Page上の1Actionに対して、usecaseのメソッドがひとつ書かれている
    • 画面で必要な情報は、基本的にドメインの型で返す
      • 画面ごとに必要な情報をusecaseがまとめることはない
    • 情報の加工が必要な場合、戻り値は次を検討する
      • 複数ドメインを返すusecaseを作る
      • 新規のドメインとして扱えるなら、ドメインを作成する
• 画面側の要求も考慮して、戻り値を考える
  • 画面に必要な情報をドメイン側にまとめてしまうと、ロジックのインタリーブになってしまう
  • そのため、usecaseが画面の要求に応じて、データを加工してあげる

2_domain

• 一般的なドメインを記述する
• infraでの処理をまとめたい場合には、infra側にrepositoryをきって、usecaseから呼び出すこともできる
  • 一般的にはドメイン層にrepository, インフラ層にrepositoryImplをつくるが、インフラ側に処理をまとめてしまうイメージ
  • ただし、必ずドメインとして扱うというルールは設けない
• 画面で何をするか、は一切考えない
  • ドメイン内での整合性や現実にそった変更ができるよう設計すること

3_infra

• 外部サービスの連携処理を記載する
  • インフラ側にDTOを切っておくことで、変更容易性が担保する
  • DTOからドメインの変換ロジックは、インフラ層では記載せず、usecase内で明示的に変換する
    • シンプルさの必要性として、DTO（やGraphQLのスキーマ）等の変更による影響を最低限に抑える
• flutter独自の設定（localizationやlogger）もひとつのサービスとみなし、パッケージをきっておく
• 各外部サービスsetup関数を用意し、view側で呼び出す
• flutter/exceptionは基本的にサービス連携部で起こるものなので、exceptionをまとめておく
  • ドメインに関わるエラーに関しては、基本的にはExceptionを投げない
  • ルール上src/配下のどこからでも参照できるため、infra内に配置する
  • エラーは基本的には３種類しか起きないと考え、引数のenum等にエラーのタイプを渡して処理を分岐する
    • 検査例外
    • 認証例外
    • 実行時例外

View部

• page配下以外のファイルは、src/配下のファイルを参照しない
  • ドメインとインタリーブせず、表示のみを主目的とする
• atomicデザインは細かすぎるので、必要最低限の粒度にする

直下

• setup_view
  • MaterialApp等、アプリの初期設定（テーマ設定など）をここに記載する
• 環境変数読み込み処理や設定ファイル等もここで良い

1_page

• ページごとの処理を記載する
• ひとつのAction（ユーザ操作等）がコントローラに相当するイメージなので、ここからusecaseを呼びだす
  • usecase呼び出しには共通のWrapperを使い、エラーハンドリング処理は一元化できる
• ページ遷移処理のロジックも記載する
  • ページ間での情報を渡すときには、こちらの引数に記載する
• src/を参照するViewはこのディレクトリ配下のページのみ

2_template

• 再利用可能なWidget
  • componentを使用したWidget
• 別PJにコピーしても使えるよう独立させる

3_component

• 再利用可能なWidget
  • 特に粒度の小さいボタンやテキストなど
• 別PJにコピーしても使えるよう独立させる