動画
要約
アプリケーションで数十年先を見据えて設計することは事実上不可能
アプリケーション設計とは「このアプリケーションを今後どうしていきたいか」を考えること
アプリケーション「維持」を目的としている事がおおい
理解しやすくあれ
なんたらアーキテクチャにこだわるな
どういうことが求められて生まれたのかの背景を学ぶ
アーキテクチャの大半は「依存管理」と「理解」を助けるための整理のルール
リアーキテクチャどうこうよりまず整理の再開を。
ディレクトリ構造とアーキテクチャは密接。
boundary 境界線
clientから外部環境への依存 Firebase Stripe Sentry
server から外部環境への依存
sharedと models という概念を設ける
models
あらゆる外部ライブラリ（React, Appllo等も）に一切依存してはならならい
npm install なくとも解釈可能な純粋なTSコードのみ
shared
外部ライブラリに少しでも依存するコード
ReactHookやComponentの共通化
Apolloのエラーハンドリング層の共通化
schema
jsonスキーマ定義とTSの型定義は全部ここへ
env
あらゆる環境変数は定数としてまとめておいたほうが管理検索しやすい
すべてstringのままにするより数値であれば parseInt() しておくなど
utils
自社ドメインに影響しない処理、オブジェクトのDeepEqualだったり
ここに入れることはかなり慎重になるべき
一番「なんでも箱」になる
守れないルールならいらない
eslint-plugin-import に手頃なルールがある
import-no-restricted-paths ↓参考
ディレクトリの増減があるとメンテが必要
任意のディレクトリから別のディレクトリへの依存を禁止にすることができる
サブディレクトリ同士の禁止も指定できる
1ディレクトリを1パッケージと捉える
ルールを守るとどうなるか
依存方向や影響範囲を理解しやすい
感想
eslintとをちゃんとやっておくのは大事だ。
ディレクトリ設計がちゃんとしているとPRをレビュアーが確認する際にこのPRの影響範囲と何をやっているかが把握できるので嬉しい。
ディレクトリ構成が整理されていると、昨日の多さや複雑さが視覚的に理解しやすい。