Upgrade to Pro — share decks privately, control downloads, hide ads and more …

FrontEnd:DDD

 FrontEnd:DDD

Frontend de KANPAI! #01 - これからフロントエンドに求められる力 -
https://frokan.connpass.com/event/57554/

Takepepe

June 21, 2017
Tweet

More Decks by Takepepe

Other Decks in Programming

Transcript

  1. Copyright © DeNA Co.,Ltd. All Rights Reserved. FrontEnd:DDD June 21,

    2017 Takefumi Yoshii Design Division DeNA Co., Ltd. Frontend de KANPAI! #01
  2. Copyright © DeNA Co.,Ltd. All Rights Reserved. FrontEnd:DDD !  吉井健⽂

    @Takepepe !  広告制作会社 -> DeNA !  WebDesigner -> FrontendEngineer !  Flash -> jQuery -> React !  ⼆児のパパ 2 ⾃⼰紹介
  3. Copyright © DeNA Co.,Ltd. All Rights Reserved. FrontEnd:DDD !  サービス事業開発(ヘルスケア)

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

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

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

    Virtual で重なり合うモーダル … observe 漏れのウィジェット …
  7. Copyright © DeNA Co.,Ltd. All Rights Reserved. DDD:JS 先のあるある事例の様な場合、SPA・⾮SPAのルーティング配下問わず、 フレームワークと異なるレイヤーでの状態管理が必須に。

    また、SPA配下では状態管理が統合できている構造が必要になる。 SPA外に発⾏するイベント・SPA外から受け付けるイベント これもまた統合できている構造が必要になる。 DDD本の第4章「レイヤードアーキテクチャ」で⽰されている 責務の分離図を⾒てみる。 12 課題の概要
  8. Copyright © DeNA Co.,Ltd. All Rights Reserved. DDD:JS 13 DDD本

    第4章 レイヤードアーキテクチャ
  9. Copyright © DeNA Co.,Ltd. All Rights Reserved. DDD:JS ドメインモデルとインフラストラクチャを据えることで、 バラバラだった機能を統合することができる。

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

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

    - かとじゅんの技術⽇誌 @かとじゅん !  複雑なJavaScriptアプリケーションを考えながら作る話 @azu_re !  React使い必⾒! Immutable.jsでReactはもっと良くなる 18 参考⽂献 考察・資料作成にあたり参考にさせていただきました。 感謝いたします!
  12. Copyright © DeNA Co.,Ltd. All Rights Reserved. DDD:CSS !  イベントが存在しない分、JSよりは分り易い依存関係

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

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

    - ドメイン・アプリケーションの境界と依存関係 -
  15. Copyright © DeNA Co.,Ltd. All Rights Reserved. DDD:CSS !  ⼿続き的な定義は⼀旦プレゼンターに委ねる

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