フロントエンド
状態を3種類に分ける。この記事が分かりやすい。
逆にこの3つを分けずに1枚板のstateでReduxで対応するみたいなのは(やったことないけど)今後やめた方がいいイメージ。
API
CQRS、そしてGraphQLが基本になるイメージ。
この記事に大体賛成。ただ、SoEがほとんどというのは違うと思う。 「データモデル＝ビジネス構造」なので、SoR領域がアジャイルにならないと、ビジネスがアジャイルにならない。
「ドメインサービス」はおそらく必要。 「アプリケーションサービス」はうまくいくイメージがない。レイヤーを増やしても解決しない。
Hasuraを用いることでQueryの95%、Mutationの20%が不要になるのは何となく自分のイメージとも合っている。
バックエンド
CRUDでなくイベントソーシングになるイメージはある。 特に「履歴」を扱うならイベントソーシングが必要。
Query側はHasuraをそのまま使うイメージでも問題ないが、Command側は基本はDDDになる。 イベントソーシングはAkka一択らしい。
ただ、まだ実装イメージは湧いていない。
関連項目
辞書
- architecture: まだありません。