DDDとRDRAを組み合わせて使うには かとじゅん(@j5ik2o) BPStudy

© Chatwork あなた誰？ ● 加藤潤一(@j5ik2o) ● Chatwork社のテックリード ○ 2016年末メッセージング基盤を刷新。k8s, Akka, Kafka, HBaseを使ったEvent Sourcing システムをリリース済み ○ PHPからScalaへのレガシーシステム移行プロ ジェクトやってます。 ● RDRAを知ったきっかけ ○ DDDのコミュニティのメンバーからの紹介

© Chatwork 最近の活動 ● #チケット料金モデリング ○ 映画の料金を決定するモデルを実装する ○ 値オブジェクトの設計に注力する ■ DBやWebAPIなどの入出力は一旦忘れる ○ セプテーニさん、オプトさんでも自主開催してくれた ● Qiita:ドメインロジックはドメインオブジェクトに凝集させる ○ 内部データをそのまま暴露するGetterは貧血症の温床になるので気 を付けろ的な話 ● DDD Radioで出演 ○ 日曜に128人ぐらいライブ方法で集まった。#dddcj

© Chatwork アジェンダ ● RDRA1.0とDDDを組み合わせた経験から以下の観点 について解説 ○ いきなりドメインモデルを考えられるか ○ ドメインモデルの周辺環境を探索する ■ システム境界 ■ システム外部環境 ■ システム価値

© Chatwork FYI: ドメインモデルとは？ ● 期日モデルの場合 ○ 期日は単なる日時ではない。期日は未来を指定する。期日は 約束事に含まれる ○ たとえば請求に含まれるのは支払期日。支払期日は請求日に 依存する。請求日から30日以内など。 ● 注文などの数量モデルの場合 ○ ただの整数ではない。Intにした場合は-21億~21億。だいた いは要件にあっていない。0~999など。 ● DDDでは問題を解く考え方(モデル)を型に落とし込む。分析と設 計(実装)を単一のモデルとして扱う。例えば請求クラスでは支払 期日クラスのインスタンスが内包される可能性が高い

© Chatwork いきなりドメインモデルを考えれるか ● 初見だと無理に近い。ドメインモデルの目的と か背景がわからないと考えられない(当然 ● ドメインモデルには抽象化のための選択と集中 がある。こういった戦略をどこから導けばよい か？ ● ドメインモデル自体は導かれた結果なので、ド メインモデルの外側に目を向けなければならな い ● ブログ記事:ドメインモデルの根拠とドメインモ デル貧血症の対策について

© Chatwork ドメインの根拠は外部環境から探る必要がある ● ドメインモデルがどのような目的で使われるか知るには、周辺環境を理 解することが求められる。RDRAはそのための手法の一つ システム システム価値 システム外部環境 システム境界 ドメイン モデル ドメイン モデル ドメイン モデル 外部システム イベント ユースケース 情 報 情 報 業務フロー/ 利用シーン

© Chatwork ドメインモデルの周辺環境を探索する ● 通常は、システム価値→システム外部環境→システム境界→システムの 流れだが、ドメインを中心に考えて逆に辿りながら考える ● Chatworkでの事例も交えながら簡単に解説 ○ OAuth2認可サーバの開発案件 ○ OAuth2がわからない人は、API利用のための認可機構だと思ってく ださい。認可＝誰に何を許可するかという問題

© Chatwork システム境界 ● システムの外部と内部の境界線を明らかにし、システ ムの範囲を明確にする

© Chatwork ユースケースモデル ● 人間とシステムの対話を明らか にすることでシステムの範囲を 明確にできる ● ユースケース記述には、ビジネ ス上で利用される概念モデルが 含まれる。そういった概念を説 明するために利用される用語が ユビキタス言語となる ● 認可APIサーバのトークンエンドポイント(B) ○ は、クライアント(E)を認証する(C) ○ は、認可コード(E)をリポジトリから読 み込み・削除する(C) ○ は、認可コード(E)を検証する(C) ○ は、認可コード(E)のリダイレクトURIと トークンリクエストのリダイレクトURI を検証する(C) ○ は、アクセストークン(E)を生成する ○ は、クライアント(E)にトークンレスポ ンスを返す(C) OAuthプロジェクトの例 用語の候補はRFCや操作マニュアルから得 られることも多い

© Chatwork FYI: システム境界とBCEステレオタイプ ● 外側から内側の対話を意識する ○ アクターとシステムの対話(外側から内側の対話)が示されている こと。必要に応じて、GUIモックアップを書く。 ● ユースケース記述を、BCE(Boundary-Control-Entity)ステレオタイプで 表現する。 ○ 名詞は、エンティティか、バウンダリオブジェクトになる。 ○ 動詞は、オブジェクト間のメッセージです。これは実装すべきソフト ウェア機能(コントロール)を示している。 エンティティ (ドメインオブジェクト ) バウンダリ コントロール (メッセージ) 名詞(オブジェクト) 動詞(処理) アクター システム アクション 応答 システム境界 業務上の動詞 に注目する。

© Chatwork FYI: イベントからドメインモデルを分析する ● RDRA1.0にもシステム境界の 段階ではユースケース以外に イベントモデルを分析する方 法もある ● 業務でどんな出来事(イベント) が起きるかに注目する。何が 発生したか。イベントの種 類、イベントが起きた時点な どからドメインモデルを分析 することができる CartCreated CartItemAdded CartItemUpdated CartItemRemoved CartCreatedにはカートIDや顧客IDや作成日 時などが含まれる。さらにどのような命令でイ ベントが起きるかを分析することができる。コマ ンドを受け取るのがドメインオブジェクト

© Chatwork ユースケースを見つけるには ● ドメインモデルをいきなり見つけることが難しいように、ユースケース も同様。RDRAでは業務フローや利用シーンから根拠を見つけることがで きる

© Chatwork システム外部環境 ● システムを取り巻く外部環境として、業務フロー・利用シーン、および 関連する概念をモデル化する

© Chatwork 利用シーン ● 利用シーン(汎用的なツールな ど) ○ システムはどのようなシー ンで利用されるか ○ 利害関係者との繋がりを示 す ● ユビキタス言語の候補が見つか る ● リソースオーナー ○ クライアントを利用したい ■ OAuth2のフローに従いリソース オーナーはクライアントに認可を 与えることができること ○ 認可を与えたクライアントを管理した い ■ 認可を与えたクライアントの一覧 を管理画面から確認でき、必要で あればその認可を失効できること OAuthプロジェクトの例

© Chatwork 概念モデル ● 業務上で使われる概念を明示的 に定義する ● 概念モデルの把握には以下の方 法などを使う ○ 声に出してテスト ○ ホワイトボードなどに説明 のためのモデル図を書く ● 用語間の結びつきに注意する ● 代表的な集約(グローバルなエンティティ) ○ クライアント ○ 予約済み認可 ○ 認可 ○ 認可コード ○ 定義済みスコープ ● 代表的な値オブジェクト ○ 組織ID ○ アカウントID ○ クライアントスコープ ○ リダイレクトURI ○ アクセストークン OAuthプロジェクトの例

© Chatwork そもそもコアドメインで仕事をしているだろうか ● 組織を成功に導くためのドメインがコアドメイン。そのコアドメインの 境界づけられたコンテキストに属するシステムの価値はどう定義される か？ ● これも、RDRAのシステム価値のパターンを使って整理・把握することが できる

© Chatwork システム価値 ● システムと関係を持つ利害関係 者や外部システム、およびシス テムに対する要求を洗い出す ● インセプションデッキやPRDにも 同様の事柄が記述される。この ようなドキュメントでコアドメ インで仕事をしているか確認す ることができる ● 価値・役割 ○ ChatWork上でOAuth2認証・認可を実現すること ● 関係者・組織 ○ システムに関わるのは、顧客組織、その組織内の管 理者(組織管理者)、リソースオーナー(CWユー ザー)、OAuth2クライアント開発者(以下、クライ アント開発者)など ● 外部システム ○ 外部システムには、ユーザーエージェント、 OAuth2クライアント(以下、クライアント)、現行 のPHPシステムなど ● 抱える問題・課題 ○ 現行APIトークンより、安全な認証・認可の基盤を 実現すること。 ● 実現する要件 ○ 組織管理者の管理下のもと、自由にクライアントを 開発でき、業務効率化を図ることができる OAuthプロジェクトの例

© Chatwork ● システムへの要求を発生させる元となる利害関 係者・外部システムを洗い出すために、コンテ キストモデルを作成する コンテキストモデル ● 関係するシステム ○ 認可管理ツール(改修対象, PHP) ○ 認可APIサーバ(開発対象, Scala) ○ 認可Webサーバ(開発対象, PHP) ○ リソースサーバ(API)(改修対象, PHP) ○ クライアント(開発対象外) ● 利害関係者 ○ 顧客組織側 ■ 組織管理者 ■ 組織内のクライアント開発者 ■ 組織内のリソースオーナー ○ 開発側 ■ 認可APIサーバチーム ■ 認可Webサーバ/リソースサーバ チーム ■ 現行PHPチーム ■ インフラチーム

© Chatwork 要求モデル ● 各アクターが持つ機能要求・ 非機能要求を洗い出す。ま た、要望・要求・要件は以下 のとおり明確に区別する ○ 要望は思いつきのレベル ○ 要求は検討対象 ○ 要件は開発対象 ● この段階でドメインとしての 価値があるかも考えることが できる。 ● クライアント開発者 ○ OAuth2を使ってクライアントを開発・運 用したい ■ クライアント開発者になりたい ■ クライアントを効率的に開発したい ■ クライアントの運用を管理したい ● リソースオーナー ○ クライアントを利用・管理したい ■ CWアカウントでクライアントの利用 したい ■ 利用中のクライアントを管理したい OAuthプロジェクトの要望例

© Chatwork まとめ ● 当然のことですが、ドメインモデルを探求するには要求が必要。ドメイ ンモデルと要求をトレースする(特にWhyのつながりのトレース)ため に、RDRAが使えるのでDDDを実践する人にもお勧めです

© Chatwork ご清聴ありがとうございました！

No content