アーキテクチャ
アーキテクチャと設計の違い
アーキテクチャのほうが上位（e.g. micro service architecture）
設計（デザイン？）の方が下位（e.g. domain driven design, design pattern）
というふわっとしたイメージがあるらしいがそういうの線引きできるものでもないし区別することに意味ないよねってクリーンアーキテクチャに書いてあった。
ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。
出典: クリーンアーキテクチャ(p.34)
何をするのがアーキテクトの仕事かというと「境界線を引き、境界線を超えるためのインタフェースを定義すること」で、それを図にすると箱（コンポーネント）や矢印を使うことになる。 #アーキテクチャを図で書くときは凡例をつける #境界線を引くと秩序が生まれる
ファイルやクラス設計レベルでのミクロなアーキテクチャ
DDD
MVC (デザインパターンだけど、方針を示すという意味ではアーキテクチャ？)
デザインパターン全般
インフラレベルでのマクロなアーキテクチャ
マイクロサービスアーキテクチャ (機能ごとに独立したリソース)
3層アーキテクチャ (Web, Application, DB)
がどちらもアーキテクチャという言葉で語られている気がする。
マクロなアーキテクチャとして機能を細かく分割できていれば、ミクロなアーキテクチャとして細かく分割する必要は少ない。
例えば、マイクロサービスアーキテクチャで作っていると、それぞれのサービス内部で細かいアーキテクチャをあまり気にせずに作っても問題が起きにくい。影響範囲をあまり気にせずに変更しても、サービス間のインタフェースを保ってさえいればそれが外部のサービスに影響することがない。
一方で、モノリシックなアーキテクチャで作っていると、マクロなアーキテクチャとして結合してしまっているので、ミクロなアーキテクチャでその影響範囲を最小にすることが求められる。
（と、いうことに最近気づいた。自分の数少ない業務経験が全てマイクロサービスアーキテクチャを採用しているシステムに関するものだったので、いわゆるDDDのようなミクロなアーキテクチャをちゃんと考える方法について学んでも（そんなに細かいところ作り込む必要ある…？）という感想が思い浮かぶのは、マクロな視点で細かく分割されているのでひとつひとつのコードベースが小さいし、ビジネスロジックの外側の詳細な部分をマネージドサービスを使っているとAWSが隠蔽してくれているからだと思った。つまりマクロなアーキテクチャとして、ビジネスロジックの実装以外を最小にする工夫が盛り込まれていた。）