アーキテクチャとネットワークの共通性

• 基本は3層。ただし実務では薄すぎるので、必要なところだけ中を分ける。
• アトミックデザインは関数を小さくすることで解決。だけれど境界が非常にわかりにくい。
• なので自分は責務で解決することにした
• DTOから分解の必要性を自覚
• アトミックデザインはコンポーネントベースアーキテクチャの“派生・整理法”
• フロントエンドアーキテクチャは「アーキテクチャそのもの」ではなく、アーキテクチャを実装に落とすための“配置ルール”に近い。
• MVC / MVVM はアーキテクチャ“全体”ではなく、UI と状態をどう分離するかの“UIパターン”】【実装寄り】

MVC

• Controller が肥大化 →Controller でなんでもやろうとする
• Model が何でも屋 →Controller が肥大化の亜種？処理の軸がModelになる
• View がロジックを持ち始める →よく見かけた。判断・加工・業務条件はなかったけど

MVVM

• MVVMは実質２層
• ReactはMVVMじゃない。双方向バインディングじゃないから

クリーン、ヘキサ、オニオン

• 六角形は数の話、円は抽象の話。増えたら全部円になる

DDD

• DDDは思想
• コードを業務の言葉で書こう
• 技術的にはどこでも変更できる。だから“変更していい場所”をAggregate に集約する、という約束をする。
• Aggregate はパケット。
• Repository は回線。
• Domain はプロトコル。
• Application：送信制御
• 全体責任者がいない設計は壊れにくい。ネットワークはその完成例。
• DDD/クリーンはそれを業務に写像している。

ビジネスプロセス
　└ ワークフロー
　　　└ ユースケース
　　　　　└ シナリオ

• システムの責任はユーザーが目的を達成できること
• DDDには「ビジネスのドメイン」と「コード上の Domain 層」という“別レイヤのドメイン”が同じ言葉で存在する
• ドメインモデルはビジネス側とエンジニア側のどちらでも理解できる言語で記述されていなければならない
• ビジネスは抽象を具体化するけど、ユーザーは具体を抽象にする
• 境界に何も無いから、責任を置ける最初の構造物――つまりユースケースに寄る。
• ユースケースはアプリケーション層
• アプリケーションとは「人や組織の“やりたいこと”を、コンピュータで実行できる形にした“道具一式”」
• pipe と compose は構文。これらはコードを便利にする。