Classi リプレイスプロジェクトフロントエンドアーキテクチャ変遷 / Classi Angular Night #4

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Copyright © 2019 Classi Corp. All Rights Reserved. Atomic Design  ● Angular CLI の Library 機能を使ったコンポーネントプロジェクトの作成  ○ Application 側のコードと完全に分離できる     NgRx  ● Redux like な状態管理ライブラリを導入し Store による状態の一元管理    4 当時(Classi Angular Night #1 時点)の取り組み 

Slide 6

Slide 6 text

Copyright © 2019 Classi Corp. All Rights Reserved. Atomic Design  ● Angular CLI の Library 機能を使ったコンポーネントプロジェクトの作成  ○ Application 側のコードと完全に分離できる     NgRx  ● Redux like な状態管理ライブラリを導入し Store による状態の一元管理    5 当時(Classi Angular Night #1 時点)のアーキテクチャ  → Presentation Domain Separation  → Redux 

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Copyright © 2019 Classi Corp. All Rights Reserved. どういうものか  ● その名の通り Presentation(UI) と Domain(ロジック) の分離  ● フロントエンドアーキテクチャを検討するとき最初に考えたい  ○ MVC や MVVM などは PDS にあたる   ● Angular は styleguide にもあるように Component と Service を意識して分割すれば PDS が実現できる  7 Presentation Domain Separation(PDS) 

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Copyright © 2019 Classi Corp. All Rights Reserved. メリット  ● 変更時の影響範囲を減らす  ○ UI とロジックは変更タイミングが異なることが多い   ○ UI の変更でロジックを気にしたくない(またはその逆)   ● テスタビリティがあがる  ○ UI はロジックに比べるとテストが難しいのでロジックを分離するほどテストしやすい範囲が増える  ● スキルセットの分離  ○ 究極的には UI は HTML / CSS と少しのロジックになるので HTML / CSS が書けるデザイナーがいる会社なら UI の保守をデザイナーができる(といいな)   9 Presentation Domain Separation(PDS) 

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Copyright © 2019 Classi Corp. All Rights Reserved. どういうものか - Redux の 3 原則  ● Single Source of Truth  ○ アプリケーション全体の状態が単一の store に格納される   ● State is read-only  ○ 状態を変更するのは常に action の発行でのみ実施   ● Changes are made with pure functions  ○ 状態の更新は Reducer を使った pure function で実施   11 Redux 

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Copyright © 2019 Classi Corp. All Rights Reserved. メリット  ● アプリケーションの状態は store を見ればわかるようになる  ● 状態を変更するのは action なので、いつどの action で状態が変わったかわかりやすくなる  ● アプリケーションが大きくなったときの下記問題が解決しやすい  ○ ユーザー入力を受け付けたりバックエンドからデータを取得したりとデータフローが複雑になる  ○ ページをまたいで管理する状態が出てくる   13 Redux 

Slide 15

Slide 15 text

Copyright © 2019 Classi Corp. All Rights Reserved. ● NgRx Effects  ○ コンポーネントの代わりにデータ fetch などの処理をまとめられる   ○ (結果としてこの役割の登場はよくなかった)   ● [Container | Presentational] component  ○ 状態を持つコンポーネントと状態を持たないコンポーネントの分離   14 Redux + α 

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Copyright © 2019 Classi Corp. All Rights Reserved. PDS  ● Domain(*service.ts) が大きくなっていった(ビジネスロジックや API Wrapper)  ● PDS はあくまで Presntation とそれ以外の分割にしか焦点を当てていない  ○ Domain 部分をどう実装するかの指標がない     Redux(NgRx)  ● Effects を多用した結果 RxJS を駆使しなければいけなくなった  ○ コードが読みにくく、テストもしづらい   16 ここまでのアーキテクチャ的な課題 

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Copyright © 2019 Classi Corp. All Rights Reserved. どういうものか  ● Presentation, Application, Domain, Infrastructure に分割    ● Presentation  ○ PDS の P と同じ  ● Domain  ○ 型情報やビジネスロジックを配置(Angular にとらわれない TS で実装)   ○ アプリケーションフレームワークにも依存しないのが理想   ● Infrastructure  ○ API Wrapper や GoogleAnalytics のための Adapter などを配置   ● Application  ○ Domain, Infrastructure 以外を配置   20 Layered Architecture 

Slide 22

Slide 22 text

Copyright © 2019 Classi Corp. All Rights Reserved. 21 Layered Architecture  Container Component Presentation 層 Service Application 層 Presentational Component Domain 層 Infrastructure 層 Repository Selector Action Reducer State Store 層 Model 呼び出し  購読 

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Copyright © 2019 Classi Corp. All Rights Reserved. どういうものか  ● コマンドクエリの分離  ○ コマンド  ■ オブジェクトの状態を変更するメソッド  ■ そのメソッドは値を戻してはいけない  ○ クエリ  ■ なんらかの値を返すメソッド  ■ オブジェクトの状態を変更してはいけない  ● 明確に分離することで  ○ 副作用が発生しないクエリと副作用が発生するコマンドを分割   ○ 変更容易性が上がり、テスト難易度は下がる   ● 今回は  ○ コマンド(*.usecase.ts)とクエリ(*.query.ts)で class を分けて CQS like に実装     24 Command Query Separation(CQS) 

Slide 26

Slide 26 text

Copyright © 2019 Classi Corp. All Rights Reserved. 25 Command Query Separation(CQS)  Container Component Presentation 層 Application 層 Presentational Component Domain 層 Infrastructure 層 Repository Selector Action Reducer State Store 層 Usecase Query Model 呼び出し  購読 

Slide 27

Slide 27 text

Copyright © 2019 Classi Corp. All Rights Reserved. メリット  ● 各層の責務が明確になる  ○ HttpClient を利用した API call → Repository   ■ ※ Repository : DDD の Repository というよりは Clean Architecture の Gateway に近い  ○ Container component 毎に必要な処理をまとめ Store への action dispatch をおこなう → Usecase  ○ 該当する View に必要な state を selector 経由で取得 → Query   ○ ビジネスロジックを Angular に依存しない pure TypeScript で書く → Domain   ● バックエンドエンジニアにも馴染みのあるシステムアーキテクチャ採用    26 Layered Architecture + CQS 