FrontEnd:DDD - Speaker Deck

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Copyright © DeNA Co.,Ltd. All Rights Reserved. FrontEnd:DDD !  サービス事業開発（ヘルスケア） !  Rails / React / Redux / CSS !  ServersideEngineer：〜10⼈ !  FrontendEngineer：〜3⼈ !  Designer：〜2⼈ 3 担当事業について本⽇の内容は⼤規模で⻑期運⽤を前提としたプロダクトをスコープとしています。実践しているものもあれば、プロトタイプレベル程度で留めているもあります。

Slide 4

Slide 4 text

Copyright © DeNA Co.,Ltd. All Rights Reserved. FrontEnd:DDD 4 ドメイン駆動設計（DDD）アプリケーションを継続的に改良していくため、ユビキタス⾔語（チームの共通⾔語）を通じて、反復的にドメインモデル（ビジネスロジックの核⼼）をグロースさせていく。【参考⽂献】エリック・エヴァンスのドメイン駆動設計（通称DDD本）複雑なアプリケーション開発のためのアーキテクチャ。アプリケーション開発の核⼼はドメインモデリングにあるとされ、分析モデルと実装モデルが同期している必要性が説かれている。

Slide 5

Slide 5 text

Copyright © DeNA Co.,Ltd. All Rights Reserved. FrontEnd:DDD 5 ドメイン駆動設計（DDD）本⽇のコンテキストは「フロントエンド実装の活動領域」「jQueryの⼿続き的な実装で乗り切ったレガシーな部分と、 React / Angular / Vue.js などを導⼊した部分が混在している」という「フロントドメインあるある」を例に、克服すべき課題を挙げ、 DDDの概念を適⽤することで、どう解決するのかを考察する。

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Copyright © DeNA Co.,Ltd. All Rights Reserved. DDD:JS 先のあるある事例の様な場合、SPA・⾮SPAのルーティング配下問わず、フレームワークと異なるレイヤーでの状態管理が必須に。また、SPA配下では状態管理が統合できている構造が必要になる。 SPA外に発⾏するイベント・SPA外から受け付けるイベントこれもまた統合できている構造が必要になる。 DDD本の第４章「レイヤードアーキテクチャ」で⽰されている責務の分離図を⾒てみる。 12 課題の概要

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Copyright © DeNA Co.,Ltd. All Rights Reserved. DDD:JS ドメインモデルとインフラストラクチャを据えることで、バラバラだった機能を統合することができる。 !  ユーザー情報などは「ドメインモデル」 !  グローバルUIは「ドメインモデル」 !  SPAのみで利⽤する様な jsonAPI等は「アプリケーションモデル」管理対象のコンテキストに適切な場所に、ビジネスロジックを据える。ドメインモデル・アプリケーションモデルにビジネスロジックを集中させることでフレームワーク依存度が下がり、再利⽤性が⾼まる。 16 ドメイン・アプリケーションの境界線

Slide 17

Slide 17 text

Copyright © DeNA Co.,Ltd. All Rights Reserved. DDD:JS モデルの実装は Immutable.js が良い。分散されがちな細かい表⽰ロジックやラベルの合成が集中できる。 Reduxでは副作⽤を委譲することができ、ドメインモデルの統合も容易。インフラストラクチャに位置するサービスは、EventEmitterを継承。サービス化を進めることで、redux-* が不要になることに気づく。サービスが複雑になってきたら rx に頼りそう。 17 ReactRedux：モデリング – 状態管理 -

Slide 18

Slide 18 text

Copyright © DeNA Co.,Ltd. All Rights Reserved. FrontEnd:DDD !  FluxとDDDの統合⽅法 - かとじゅんの技術⽇誌 @かとじゅん !  複雑なJavaScriptアプリケーションを考えながら作る話 @azu_re !  React使い必⾒！ Immutable.jsでReactはもっと良くなる 18 参考⽂献考察・資料作成にあたり参考にさせていただきました。感謝いたします！

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Copyright © DeNA Co.,Ltd. All Rights Reserved. DDD:CSS !  イベントが存在しない分、JSよりは分り易い依存関係 !  CSS のモデルは UIコンポーネント !  Bootstrap はモデルとして機能していると⾔える !  利⽤者はプレゼンテーショナルな定義と微調整のみで良い !  モデルを抽象化、エンティティとして利⽤ !  UI/UX の拡張に伴い、モデルをマイグレートさせる !  UI/UX がグロースすることで、モデルが豊かになっていくことが理想 20 CSS設計：ドメインモデル

Slide 21

Slide 21 text

Copyright © DeNA Co.,Ltd. All Rights Reserved. DDD:CSS !  CSS設計に応じて、4つの層のどこに属している定義なのか意識 !  プレフィクスで分離されているCSS設計なら認識しやすい !  ドメイン・アプリケーションのコンテキストを分離 !  FLOCSSでいう Components と Projects の分離担当事業で採⽤しているCSS設計図にDDDの4つの層を当ててみる。 21 CSS設計：モデリング

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Copyright © DeNA Co.,Ltd. All Rights Reserved. DDD:CSS !  ⼿続き的な定義は⼀旦プレゼンターに委ねる !  エンティティが表⾯化した時、モデル・ドメインにマイグレート !  BOXモデルが関⼼の分離を侵⾷しない様に注意 !  アプリケーションプレゼンターなら css modules もアリ !  それでも、責務の識別と e2eテストツールの都合からBEMに落ち着く【その他設計上の規約】 !  詳細度とコンテキストの解決は最初から整備しておく !  ⾼階コンポーネントModiﬁer から受ける作⽤を必要に応じて開けておく !  状態でコンポーネントを管理するのではなく、コンポーネントが状態を管理 !  マルチクラスModiﬁerを採⽤、カプセル化 !  ⽤法容量を守った⾶び道具 25 CSS設計：モデルのマイグレート