Big Ball of Mud
Monolith
- 非構造化モノリス
- レイヤ化アーキテクチャ
- モジュール式モノリス
- マイクロカーネル
EDA(Event Driven Architecture)
- Brokerパターン
- Mediatorパターン
サービス指向アーキテクチャ
- ESB駆動SOA
- マイクロサービス
- サービスベースアーキテクチャ
サーバーレスアーキテクチャ
ビジネスロジックとビュー本体の分離が新しい分野
移行のボトルネック・基準
ビジネス機能グループ
トランザクション境界
デプロイメント目標
直面する問題の流れ
スパゲッティコード問題
- フレームワークやライブラリの導入、正しい理解
MVC等になっていない問題
- 単一責任の原則
MVC等になっているがcontrollerやmodelが大きすぎる問題
- アーキテクチャの分離の問題
管理画面やアプリコードなど色々くっつきすぎ問題
- ビジネスロジックの分離の問題
デプロイ・スケーリング問題、主にメモリとCPU
- インフラの分離の問題
データベースへのアクセス問題、主にプロセス
- 永続化層の分離の問題
コスト面での歴史
Unix > 言語 > ツール > フレームワーク・ライブラリ
インフラが高価だった時代
- オープンソース言語が生まれたため拡張性は言語で担保
インフラが高価ではなくなった
- 言語はシンプルに保ち、アーキテクチャで担保
データに基づいた設計とデザインに基づいた設計
- データがどれくらい結合しているかを発見するための設計
- どのように表示させたいかをもとにした設計
- バリデーションをデータでかけるかデザインでかけるか
結合をどのように定義するか、そもそもキーが必要なのか
表示方法
検索(必要なくなってきた)
比較(必要なし)
メモ化(ローカルストレージ)(場合による)
永続化(リモートストレージ)(場合による)
通知(必要なし)
取引(必要なし)
キーの２つの役割
- IDentifier
- 検索
リストでの表示と単一での表示(REST)
リストでの表示
- ランキング
- 相関関係
- 関連
単一での表示
- 何らかのIDでの表示
- もっとも当てはまると思われるものの表示
ステートレス・ステートフル
状態とはなんであるか
ステートレスでないと理解が難しい理由
本質的にステートフルな要素は時間
時間が関係する要素をどのように表現するか
トランザクションが発生するかどうか
トランザクションとはステートの遷移の表現でもあり、究極的には時間によるデータの変化
サーバーレスが向いているもの向いていないもの
サーバーレスが向いている
記事の表示
検索
比較
永続化
- 記事サイト
- 比較サイト
サーバーレスが向いていない
取引
時間が関連するデータを扱うもの?
- 予約サイト
グラフデータベース
ビジネスロジック==リレーション
有用なデータ==リレーション
に限りなく近づいていく
データ自体はストレージや構造化されたデータとして保存してあればよい。
構造化されたデータもしく、限られた時間内に検索されたクラスタの意味の結びつきを表現するために、グラフさえあればよい。
そうするとスキーマの変更が比較的無制限に出来る。条件に合わないデータを除外する処理をいれればよい。
データが追加されるたびに、グラフが更新される。
インサートは考慮するべきトランザクションが減り、並行性が高くなる。
検索は逆に並行性が低くなる。
Neo4jが有名