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

DDDとRDRAを組み合わせて使うには

 DDDとRDRAを組み合わせて使うには

RDRA1.0とDDDを組み合わせた経験から以下の観点 について解説
1) いきなりドメインモデルを考えられるか
2) ドメインモデルの周辺環境を探索する

かとじゅん

September 24, 2019
Tweet

More Decks by かとじゅん

Other Decks in Programming

Transcript

  1. © Chatwork あなた誰? • 加藤潤一(@j5ik2o) • Chatwork社のテックリード ◦ 2016年末メッセージング基盤を刷新。k8s, Akka,

    Kafka, HBaseを使ったEvent Sourcing システムをリリース済み ◦ PHPからScalaへのレガシーシステム移行プロ ジェクトやってます。 • RDRAを知ったきっかけ ◦ DDDのコミュニティのメンバーからの紹介
  2. © Chatwork 最近の活動 • #チケット料金モデリング ◦ 映画の料金を決定するモデルを実装する ◦ 値オブジェクトの設計に注力する ▪

    DBやWebAPIなどの入出力は一旦忘れる ◦ セプテーニさん、オプトさんでも自主開催してくれた • Qiita:ドメインロジックはドメインオブジェクトに凝集させる ◦ 内部データをそのまま暴露するGetterは貧血症の温床になるので気 を付けろ的な話 • DDD Radioで出演 ◦ 日曜に128人ぐらいライブ方法で集まった。#dddcj
  3. © Chatwork FYI: ドメインモデルとは? • 期日モデルの場合 ◦ 期日は単なる日時ではない。期日は未来を指定する。期日は 約束事に含まれる ◦

    たとえば請求に含まれるのは支払期日。支払期日は請求日に 依存する。請求日から30日以内など。 • 注文などの数量モデルの場合 ◦ ただの整数ではない。Intにした場合は-21億~21億。だいた いは要件にあっていない。0~999など。 • DDDでは問題を解く考え方(モデル)を型に落とし込む。分析と設 計(実装)を単一のモデルとして扱う。例えば請求クラスでは支払 期日クラスのインスタンスが内包される可能性が高い
  4. © Chatwork いきなりドメインモデルを考えれるか • 初見だと無理に近い。ドメインモデルの目的と か背景がわからないと考えられない(当然 • ドメインモデルには抽象化のための選択と集中 がある。こういった戦略をどこから導けばよい か?

    • ドメインモデル自体は導かれた結果なので、ド メインモデルの外側に目を向けなければならな い • ブログ記事:ドメインモデルの根拠とドメインモ デル貧血症の対策について
  5. © Chatwork ユースケースモデル • 人間とシステムの対話を明らか にすることでシステムの範囲を 明確にできる • ユースケース記述には、ビジネ ス上で利用される概念モデルが

    含まれる。そういった概念を説 明するために利用される用語が ユビキタス言語となる • 認可APIサーバのトークンエンドポイント(B) ◦ は、クライアント(E)を認証する(C) ◦ は、認可コード(E)をリポジトリから読 み込み・削除する(C) ◦ は、認可コード(E)を検証する(C) ◦ は、認可コード(E)のリダイレクトURIと トークンリクエストのリダイレクトURI を検証する(C) ◦ は、アクセストークン(E)を生成する ◦ は、クライアント(E)にトークンレスポ ンスを返す(C) OAuthプロジェクトの例 用語の候補はRFCや操作マニュアルから得 られることも多い
  6. © Chatwork FYI: システム境界とBCEステレオタイプ • 外側から内側の対話を意識する ◦ アクターとシステムの対話(外側から内側の対話)が示されている こと。必要に応じて、GUIモックアップを書く。 •

    ユースケース記述を、BCE(Boundary-Control-Entity)ステレオタイプで 表現する。 ◦ 名詞は、エンティティか、バウンダリオブジェクトになる。 ◦ 動詞は、オブジェクト間のメッセージです。これは実装すべきソフト ウェア機能(コントロール)を示している。 エンティティ (ドメインオブジェクト ) バウンダリ コントロール (メッセージ) 名詞(オブジェクト) 動詞(処理) アクター システム アクション 応答 システム境界 業務上の動詞 に注目する。
  7. © Chatwork FYI: イベントからドメインモデルを分析する • RDRA1.0にもシステム境界の 段階ではユースケース以外に イベントモデルを分析する方 法もある •

    業務でどんな出来事(イベント) が起きるかに注目する。何が 発生したか。イベントの種 類、イベントが起きた時点な どからドメインモデルを分析 することができる CartCreated CartItemAdded CartItemUpdated CartItemRemoved CartCreatedにはカートIDや顧客IDや作成日 時などが含まれる。さらにどのような命令でイ ベントが起きるかを分析することができる。コマ ンドを受け取るのがドメインオブジェクト
  8. © Chatwork 利用シーン • 利用シーン(汎用的なツールな ど) ◦ システムはどのようなシー ンで利用されるか ◦

    利害関係者との繋がりを示 す • ユビキタス言語の候補が見つか る • リソースオーナー ◦ クライアントを利用したい ▪ OAuth2のフローに従いリソース オーナーはクライアントに認可を 与えることができること ◦ 認可を与えたクライアントを管理した い ▪ 認可を与えたクライアントの一覧 を管理画面から確認でき、必要で あればその認可を失効できること OAuthプロジェクトの例
  9. © Chatwork 概念モデル • 業務上で使われる概念を明示的 に定義する • 概念モデルの把握には以下の方 法などを使う ◦

    声に出してテスト ◦ ホワイトボードなどに説明 のためのモデル図を書く • 用語間の結びつきに注意する • 代表的な集約(グローバルなエンティティ) ◦ クライアント ◦ 予約済み認可 ◦ 認可 ◦ 認可コード ◦ 定義済みスコープ • 代表的な値オブジェクト ◦ 組織ID ◦ アカウントID ◦ クライアントスコープ ◦ リダイレクトURI ◦ アクセストークン OAuthプロジェクトの例
  10. © Chatwork システム価値 • システムと関係を持つ利害関係 者や外部システム、およびシス テムに対する要求を洗い出す • インセプションデッキやPRDにも 同様の事柄が記述される。この

    ようなドキュメントでコアドメ インで仕事をしているか確認す ることができる • 価値・役割 ◦ ChatWork上でOAuth2認証・認可を実現すること • 関係者・組織 ◦ システムに関わるのは、顧客組織、その組織内の管 理者(組織管理者)、リソースオーナー(CWユー ザー)、OAuth2クライアント開発者(以下、クライ アント開発者)など • 外部システム ◦ 外部システムには、ユーザーエージェント、 OAuth2クライアント(以下、クライアント)、現行 のPHPシステムなど • 抱える問題・課題 ◦ 現行APIトークンより、安全な認証・認可の基盤を 実現すること。 • 実現する要件 ◦ 組織管理者の管理下のもと、自由にクライアントを 開発でき、業務効率化を図ることができる OAuthプロジェクトの例
  11. © Chatwork • システムへの要求を発生させる元となる利害関 係者・外部システムを洗い出すために、コンテ キストモデルを作成する コンテキストモデル • 関係するシステム ◦

    認可管理ツール(改修対象, PHP) ◦ 認可APIサーバ(開発対象, Scala) ◦ 認可Webサーバ(開発対象, PHP) ◦ リソースサーバ(API)(改修対象, PHP) ◦ クライアント(開発対象外) • 利害関係者 ◦ 顧客組織側 ▪ 組織管理者 ▪ 組織内のクライアント開発者 ▪ 組織内のリソースオーナー ◦ 開発側 ▪ 認可APIサーバチーム ▪ 認可Webサーバ/リソースサーバ チーム ▪ 現行PHPチーム ▪ インフラチーム
  12. © Chatwork 要求モデル • 各アクターが持つ機能要求・ 非機能要求を洗い出す。ま た、要望・要求・要件は以下 のとおり明確に区別する ◦ 要望は思いつきのレベル

    ◦ 要求は検討対象 ◦ 要件は開発対象 • この段階でドメインとしての 価値があるかも考えることが できる。 • クライアント開発者 ◦ OAuth2を使ってクライアントを開発・運 用したい ▪ クライアント開発者になりたい ▪ クライアントを効率的に開発したい ▪ クライアントの運用を管理したい • リソースオーナー ◦ クライアントを利用・管理したい ▪ CWアカウントでクライアントの利用 したい ▪ 利用中のクライアントを管理したい OAuthプロジェクトの要望例