現場のアーキテクチャの話をしてみませんか？
概要
DevLove関西主催の勉強会
変化と依存
・UIは理解しやすく、変化しやすい
顧客の担当変更により簡単に仕様が変わる。
DBの構造等は変わらない。
・Dataの変更はLogic・UIに影響する
UIの変更はLogic・UIに影響するとは限らない
・結論、データ、ビジネスロジックから開発し、UIは最後に作ると、
手戻りが少ない開発が行える。
・データ、ビジネスロジック、UI層を分化し、
UIの変化が他に影響しない構造を作る
「レイヤードアーキテクチャー」参照
判断レベルの推移
アーキテクチャ哲学
・アーキテクチャは選択の集合体
・アーキテクチャ魂＝自分ならコウする
しかし判断の根拠が必要。立場、役割、目的毎に
「アーキテクチャの判断指標」参照
・トレードオフが必要。
しかし平均点は高くなくても良い。
一部の重点項目が良ければ他は要望を満たしてなくても良い場合もある
・目の前の要求に惑わされない
・未来に共感せよ
・アーキテクチャの目的は伝える事(未来へのバトン)
アーキテクチャで用いる図では１つの視点に集中する
他の視点は他の図で表す
・リスクに敏感になれ。しかしリスクを恐れない
・未来を感じろ。誰も教えてくれない。
・自分で感じた未来を信じろ
レイヤードアーキテクチャー
※＝レイヤ化～/階層化～/多層～
処理を分類する
例
・OSI参照モデル
・MVC
MVCモデルにおいては
×：Controller > Model
○：Controller < Model
だが全てをModelに書くと大規模なアプリケーションでは結局分かり難くなる。
各層の責務(ルール)を決める
↓↑View(Routing)
※(1)ルーティング/認証/フィルタリング
↓↑Controller
※(2)HTTPリクエスト/レスポンス/バリデーション/Serviceの実行
↓↑Service
※(3)ビジネスロジック内容での検証/ビジネスロジック
↓↑Model
※(4)DBアクセス
・処理を分離する
(1)～(2)では文字の不正検証等のみを行い、
(3)ではビジネスロジックとしての検証を行う(在庫数や社員在籍有無等)
・流れを一方向に固定する
・クラス/メソッド名はドメイン用語
・ドメイン毎、ビジネスロジック毎に名前空間を分ける
・サービスから作る(その後→テスト→UI)
アーキテクチャの判断指標
| セキュリティ | 性能 | 可用性 | 発展性 | |
|---|---|---|---|---|
| 機能 | ✔ | ✔ | ✔ | ✔ |
| 情報 | ✔ | ✔ | ✔ | ✔ |
| 並行性 | ✔ | ✔ | ✔ | ✔ |
| 開発 | ✔ | ✔ | ✔ | ✔ |
| 配置 | ✔ | ✔ | ✔ | ✔ |
| 運用 | ✔ | ✔ | ✔ | ✔ |
１週間でできる会員サイト「Limited」
必要最小限。だから分かりやすい。始めやすい。続けやすい。
限定① 安⼼・安全の会員制
限定② 必要最⼩限の機能
限定③ 独⾃機能を追加可能
