RDRA1.0とDDDを組み合わせた経験から以下の観点 について解説 1) いきなりドメインモデルを考えられるか 2) ドメインモデルの周辺環境を探索する
DDDとRDRAを組み合わせて使うにはかとじゅん(@j5ik2o)BPStudy
View Slide
© 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を組み合わせた経験から以下の観点について解説○ いきなりドメインモデルを考えられるか○ ドメインモデルの周辺環境を探索する■ システム境界■ システム外部環境■ システム価値
© ChatworkFYI: ドメインモデルとは？● 期日モデルの場合○ 期日は単なる日時ではない。期日は未来を指定する。期日は約束事に含まれる○ たとえば請求に含まれるのは支払期日。支払期日は請求日に依存する。請求日から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や操作マニュアルから得られることも多い
© ChatworkFYI: システム境界とBCEステレオタイプ● 外側から内側の対話を意識する○ アクターとシステムの対話(外側から内側の対話)が示されていること。必要に応じて、GUIモックアップを書く。● ユースケース記述を、BCE(Boundary-Control-Entity)ステレオタイプで表現する。○ 名詞は、エンティティか、バウンダリオブジェクトになる。○ 動詞は、オブジェクト間のメッセージです。これは実装すべきソフトウェア機能(コントロール)を示している。エンティティ(ドメインオブジェクト )バウンダリコントロール(メッセージ)名詞(オブジェクト) 動詞(処理)アクター システムアクション応答システム境界業務上の動詞に注目する。
© ChatworkFYI: イベントからドメインモデルを分析する● RDRA1.0にもシステム境界の段階ではユースケース以外にイベントモデルを分析する方法もある● 業務でどんな出来事(イベント)が起きるかに注目する。何が発生したか。イベントの種類、イベントが起きた時点などからドメインモデルを分析することができるCartCreatedCartItemAddedCartItemUpdatedCartItemRemovedCartCreatedにはカート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ご清聴ありがとうございました！
j5ik2o
quramy
miyabigouji
daisukeshinoku
shumpei0111
jmatsu
akitotsukahara
ogom
tkhs0604
tsukushi
lhespanha
mh4gf
shohata
bkeepers
hatefulcrawdad
akosma
smashingmag
jrom
cassininazir
skipperchong
sstephenson
colly
maggiecrowley
jmmastey
malarkey