突撃!!隣のアーキテクチャに行ってきました。簡単に所感をまとめます。
totsugeki-architecture.connpass.com
所感
ちょっと予習不足なところもあって若干理解できてないところもありましたが、他のひとがどのようなことを考えてアーキテクチャ設計しているのかを聴けてとても勉強になりました。わりとリアルな現場の話が聴けてよかったです。
ユビキタス言語がブレた場合、どういう過程を経てコードまで落とし込むんだろうか。アジャイル的に細かいサイクルで変更を取り込んでいく感じなのかな。
あと、自分の周りではわりと機能単位でパッケージを切ってるケースが多い印象だけど、レイヤごとにパッケージを切るのがよさそう。たぶん、これが Clean Architecture というものだと思われる。要勉強。
以下、メモから抜粋。
SUGARのアーキテクチャ - SUGAR
- イメージは Clean Architecture
- View > Adapter > Application > Domain
- 内側のものだけ利用できる
- Infrastructure は他から利用されるもの
- 同じ存在でもサーバー/クライアントで呼び方が違うことがある☆
- Application
- 必要な Domain 層の実装を組み合わせて意味のある単位にまとめる役割
- DI された Domain 層の実装を組み合わせて何かしら意味のある処理にする実装を置く
- Adapter
- Domain 層の実装を置く
- json の相互変換はここでやる
- View
CQRS+ES(再)入門 - Chatwork
- Chatwork のバックエンドは CQRS+ES
- 伝統的なアプローチ
- データ指向からコマンド指向に
- クライアントからコマンドを送信する
- コマンドによって意図が明白なIFを作る
- 命令の文脈を表したコマンドをモデルとする☆
- コマンドとクエリの要件は違う☆
- 一貫性、データ形式、スケーラビリティ
- クエリサイド
- コマンドサイド
- ドメインオブジェクトは内部状態を外部に晒す必要がない
- コマンドの処理以外に必要なクエリメソッドは持たない
- ドメインイベント (コマンドとクエリの結合)
- 過去に発生したできごと
- イベントがわかればコマンドがわかる
- Event Sourcing
- イベントはイミュータブルな歴史を表す
- ドメインイベントの追加はロック不要
- パーティショニング (集約IDで書き込みを分散できる)
- イベント列から最新の状態を得る
- イベント列が大量にある場合は時間がかかる
- スナップショットを持たせる
AbemaTV iOS Architecture - AbemaTV
- Presentation Domain Separation
- MVVM + Flux
- Flux は Store が大量のロジックを持ちがち
- ViewModel
- グローバルで状態を持つ必要がない場合は ViewModel を使う
- Flux を小さくする方針
- ライフライクルが明確で管理がラク (View のライフサイクルに依存する)
- メッセージングがリレーだらけになる
- Unio☆
- 自由度が高く実装がバラバラになりがちな ViewModel を矯正する
Mirrativ Androidアプリの取り組み
- ユビキタス言語がブレる
- 開発当初から呼び方が変わる
- Android Architecture Components
- 推奨アーキテクチャは MVVM
- パッケージ構造
- 機能単位からレイヤー単位に
- 将来的には機能ごとにサブモジュール化する
DIライブラリ Airframeを使ってみた
- Scala 向けの DI コンテナ
- https://github.com/wvlet/airframe
GoでのAPI開発現場のアーキテクチャ実装事例
- Layeredish Architecture☆
- パッケージ構成☆
- Domain に repository のインタフェースを置く
- Infrastructure に repository インタフェースの実装を置く
- 技術的実装☆
- Application は制御の役割を担う
- 各レイヤのインタフェースを実装したテストダブルを作成して使う
