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

DDDで利用するアーキテクチャと プレゼンテーション層について/DDD Architecture

Tomoyoshi Ogura
September 07, 2016

DDDで利用するアーキテクチャと プレゼンテーション層について/DDD Architecture

2016-09-07に行われた「Design For User #2 - コンポーネント指向から考えるUIと設計」で発表した時の資料です。

Tomoyoshi Ogura

September 07, 2016
Tweet

More Decks by Tomoyoshi Ogura

Other Decks in Design

Transcript

  1. Design For User #2 DDDで利用するアーキテクチャと プレゼンテーション層について Tomoyoshi Ogura 2016/09/07

  2. 自己紹介 • 小椋友芳 • ChatWork株式会社 CTO室所属 • ソフトウェアエンジニア • Scala、Akka、Golang、DDD

    • twitter: @tomoyoshi_ogura • github: tarugo07
  3. アジェンダ • Smart UIとDDDについて • DDDを実践するためのアーキテクチャ • プレゼンテーション層ファースト

  4. Smart UIパターンとDDD

  5. Smart UIパターンとは • 画面(UI)をベースに設計、実装を行うこと

  6. Smart UIパターンの特徴 • 生産性が高くすぐに形にできる ◦ 単純なアプリ開発に向いている • 要件分析が不足していても問題にならない • 開発者に高いスキルは求めない

    • 引き継ぎが特に必要ない • ふるまいやビジネスルールがUIのロジックに埋もれてしまう • 保守・運用が困難 ◦ UIが変わったら作り直しになる ◦ 修正の影響範囲が分かり難い
  7. ドメイン駆動設計 • 利用する人の関心事に着目する ◦ Smart UIアンチパターン • ソフトウェアの複雑さに立ち向かう • ユビキタス言語

    ◦ ドメインエキスパートやソフトウェア開発者を含めたチーム全体で作り上げる共 通言語 • 境界づけられたコンテキスト ◦ ドメインモデルやユビキタス言語が同じ意味で使える範囲 • ドメインモデル
  8. 詳しくは読みましょう

  9. アーキテクチャ

  10. レイヤードアーキテクチャ

  11. レイヤードアーキテクチャ • ドメインを隔離させる • UI、アプリケーション、ドメイン、インフラストラ クチャの四層で構成される • 依存関係は上から下 • レイヤーごとのモデル変換が必要

  12. クリーンアーキテクチャ

  13. クリーンアーキテクチャ • ドメインを中心に考える • 外部機能が独立 ◦ UI、データベース、外部サービスのAPI • 内側の層にのみ依存 •

    ユースケース層がある ◦ アプリケーション固有のビジネスルール • 依存関係逆転の法則 (DIP : Dependency Inversion Principle) ◦ ドメインがインフラストラクチャに依存しない • https://8thlight.com/blog/uncle-bob/2012/08/13/th e-clean-architecture.html
  14. プレゼンテーション層ファースト

  15. ドメインが定義できない • ドメインエキスパートがいない • スタートアップ • 新規開発

  16. どうするか • プレゼンテーション層を先にやる • UXファースト ◦ スケッチ、ワイヤーフレーム、モックアップ • プレゼンテーション層に目処がついたらDDD ◦

    アプリケーションの関心事が整理できてる ◦ ユビキタス言語とコンテキストをきめる
  17. まとめ • Smart UIはやめましょう ◦ 簡単なアプリケーションは除く • 複雑な関心事のアプリケーションはDDD ◦ ただしコストはかかる

    • 関心事が明確にできない時はプレゼンテーション層から ◦ 立ち止まってDDDをはじめよう