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

自己紹介 ● 小椋友芳 ● ChatWork株式会社 CTO室所属 ● ソフトウェアエンジニア ● Scala、Akka、Golang、DDD ● twitter: @tomoyoshi_ogura ● github: tarugo07 

アジェンダ ● Smart UIとDDDについて ● DDDを実践するためのアーキテクチャ ● プレゼンテーション層ファースト 

Smart UIパターンとDDD 

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

Smart UIパターンの特徴 ● 生産性が高くすぐに形にできる ○ 単純なアプリ開発に向いている ● 要件分析が不足していても問題にならない ● 開発者に高いスキルは求めない ● 引き継ぎが特に必要ない ● ふるまいやビジネスルールがUIのロジックに埋もれてしまう ● 保守・運用が困難 ○ UIが変わったら作り直しになる ○ 修正の影響範囲が分かり難い 

ドメイン駆動設計 ● 利用する人の関心事に着目する ○ Smart UIアンチパターン ● ソフトウェアの複雑さに立ち向かう ● ユビキタス言語 ○ ドメインエキスパートやソフトウェア開発者を含めたチーム全体で作り上げる共 通言語 ● 境界づけられたコンテキスト ○ ドメインモデルやユビキタス言語が同じ意味で使える範囲 ● ドメインモデル 

詳しくは読みましょう 

アーキテクチャ 

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

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

クリーンアーキテクチャ 

クリーンアーキテクチャ ● ドメインを中心に考える ● 外部機能が独立 ○ UI、データベース、外部サービスのAPI ● 内側の層にのみ依存 ● ユースケース層がある ○ アプリケーション固有のビジネスルール ● 依存関係逆転の法則 (DIP : Dependency Inversion Principle) ○ ドメインがインフラストラクチャに依存しない ● https://8thlight.com/blog/uncle-bob/2012/08/13/th e-clean-architecture.html 

プレゼンテーション層ファースト 

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

どうするか ● プレゼンテーション層を先にやる ● UXファースト ○ スケッチ、ワイヤーフレーム、モックアップ ● プレゼンテーション層に目処がついたらDDD ○ アプリケーションの関心事が整理できてる ○ ユビキタス言語とコンテキストをきめる 

まとめ ● Smart UIはやめましょう ○ 簡単なアプリケーションは除く ● 複雑な関心事のアプリケーションはDDD ○ ただしコストはかかる ● 関心事が明確にできない時はプレゼンテーション層から ○ 立ち止まってDDDをはじめよう