これ何と目的
これは?
社内勉強会で話した内容のまとめです。擬人化の部分を削除しています
目的
昨今のアーキテクチャ事情を簡単に確認するためのものです
内容
「アーキテクチャの目的」ってなんだろうを横目で見つつ
「Flux」「Clean」「Reactive Programing」をの比較をしてみたものです
アーキテクチャの目的
システム、アプリケーションの構造とデータフロー、依存関係の定義
-
アーキテクチャの選択からの結果
- 共通認識、作業イメージ
- 作りやすい、保守しやすいの判断基準
- 問題の切り分け "フレームワーク選択", "障害箇所判定", "スケールアウト, スケールアップ"
つまるところダメなアーキテクチャとは
- 構造、データフロー、依存関係が不明
- 認識しづらい。どうやって作るの?
- これここでやるんですか?どこにあるんでしたっけ?
- 存在自体が負債
取り上げるアーキテクチャと目的視点別コメント
Archtecture | 構造 | データフロー | 依存関係 | 作り易さ/保守性 |
---|---|---|---|---|
Flux | action creator, dispatcher , callback/store , view の4つの要素で解決 | 一方向 | データフローで定義した順序 | フロントエンドをこれで作成することに問題はない。(これだって感じもしない。自分の場合) |
Clean | 分類が多数あるので境界について議論が必要 | 一方向、双方向可能 | 依存関係は単一方向 | 難しくないが、冗長になる要素を含んでいるので失敗すると大変になる模様 |
ReactivePrgraming | ストリームの定義に依存 | イベントの発生時のみ | ストリームとイベントの関係 | 簡素になるが、知らない人が見ると訳わからない可能性がある |
取り上げるアーキテクチャとまとめ
Archtecture | メリット | デメリット |
---|---|---|
Flux | 導入が楽で、高速に開発が行える | 思想とマッチしていないモジュールがあると、組み込みにくい |
Clean | ある程度正確に分類することができる | 冗長に作り込んでしまうと保守性や生産性を落とす可能性がある |
ReactivePrgraming | 洗練して簡素に記述できる | メンバーにスキルを要求してくるので導入する場合は民度を見る必要がある |
参考
-
FluxとDDD(レイヤードアーキテクチャ)について考えてみた
- 書いている内容をこれを書くのに参考にしました
-
擬人化アーキテクチャ
- 勉強会資料
-
参照実装コード
- コードの話は別のもので書きます