突撃!!隣のアーキテクチャ
CQRS+ES(再)入門 - Chatwork - かとじゅん
Command and Query Responsibility Segregation
モデル状態の全てはデータベースにある
最新を取得しなければならない
更新の衝突会費にはロックが必要
シンプルでチームがスケールしやすい
ツールのサポートはあるがDDDがやりにくい
RDBMSに頼りっきりなのでスケールしにくい
CRUDはDDDに向かない
CRUDの動詞はデータ指向
ユビキタス言語が曖昧になりがちで、設計の意図が失われている
setter/getterだらけになって設計の意図がわからなくなってしまう
データ指向からコマンド指向へ
アプリケーションサーバーが何をするのかを示したコマンドを表現できる
ユビキタス言語にフォーカスできるようになる
CreateUser()なのか、RegisterUser()なのか
CRUDの支配から脱出できる
CQRSで変わるドメインモデリング
チャットルームの直近24hは編集可能だがそれ移行は編集できないケース
CQRS+ESで編集できること
CQRS
Event Sourcing
AbemaTV iOS Architecture - AbemaTV to4iki
アプリ開発における設計
クライアントサイドプログラミングの主目的
APIレスポンスをどのように画面に反映するか
データ状態をどのように画面に反映するか
理想のUIをどのように画面に反映するか
アプリ開発の課題
画面に反映する状態が複雑
AbemaTVの場合
番組、CM、コメント、ユーザー、etc...
様々な状態がいて複雑
どのように複雑な状態を解決していくか？
AbemaTV
MVVM + Flux
Flux
GUIアーキテクチャパターン
データの方向が1方向になっているのが特徴
Abemaでは RxSwiftを用いて実装している
結合テストが楽
複数画面からsubscribeされるため処理が追いづらい
Storeが大量のオブジェクトを持つようになる
Dispatcher
Action
Store
MVVM
Model
ビジネスロジック
View
ユーザーからの入力
ViewModel
プレゼンテーションに関するロジック
状態のライフサイクル管理が楽
単体テストが楽
メッセージングがリレーだらけになる
再利用が低い
自由度が高く、各自の実装がバラバラになりがち
Unio
Unidirectional Input / Output framework with RxSwift
1画面で収まるデータは、MVVMを使う
アプリの設計は、どのように複雑な状態を把握・管理するかが鍵
MVVM+FLuxを適材適所で使い分ている
Mirrativ Androidアプリの取り組み(仮 - Mirrativ morizooo
Mirrativ
ゲーム配信アプリ
友達の家でドラクエやってるような感じ
パッケージ構成
feature配下に機能単位にパッケージを切ってUIを設置
カオス化
課題
どこに処理を書くか
厳密なルールがなくてActivityに処理が集中してしまう
Android Architecture Components
Model
クライアントに特化したAPIをサーバーで返しているので、Responseはそのまま描画するだけ
View
情報を表示するだけ
プレゼンテーション/ビジネスロジックは持たない
Modelを直接参照してはだめ
Controller
Modelを取得
Viewに描画するデータを設定する
一旦FATにして整理してからまとめる
Kotlin化
Java<>Kotlin間のコンテキストスイッチをなくす
親までたどってnullチェックをするのがしんどい
GoでのAPI開発現場のアーキテクチャ実装事例 - Kazuki Higashiguchi
BASE BANK
Goでのアーキテクチャ事例があんまりみつからない
変更用意性・実装の統一性・てスタビリティを担保した結果を紹介
Layered "ish" Architecture + ポート・アダプタ
repositoryパッケージ
getByIDなどのメソッドを用意し、ロジックが使う
Service
ひとつのServiceごとにInterface型を実装
Controller
ハンドラ等が定義されている
ElmでSPA State設計 - ス（ズキ）
HRBrain
SPAの難しさ
運用画面、管理画面の話
ページ間で状態を管理しているから予期せぬ動作が起こる
ページごとに状態を管理する
SSRと同じじゃね？