Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
DDDとRDRAを組み合わせて使うには
Search
かとじゅん
September 24, 2019
Programming
10
4.4k
DDDとRDRAを組み合わせて使うには
RDRA1.0とDDDを組み合わせた経験から以下の観点 について解説
1) いきなりドメインモデルを考えられるか
2) ドメインモデルの周辺環境を探索する
かとじゅん
September 24, 2019
Tweet
Share
More Decks by かとじゅん
See All by かとじゅん
メッセージとイベントを中核に置いたシステム設計の有用性について
j5ik2o
10
2.8k
私のキャリアの旅路: 技術をきっかけに変化を楽しむ
j5ik2o
3
770
いかに開発効率と品質を高めるか: ドメイン駆動設計と組織パターンの視点から考える
j5ik2o
3
2.3k
社内のメンバーに「関数型プログラミングの学習・教育」についていろいろ聞いてみた
j5ik2o
2
1.7k
AWS データベースブログの記事 「Amazon DynamoDBによる CQRSイベントストアの構築」 を勝手に読み解く
j5ik2o
2
2.6k
EIPとAkkaについて
j5ik2o
3
2.5k
モデルを中心にデザイン(設計)すること
j5ik2o
2
2.6k
ドメインイベントの観点から再考するソフトウェア設計
j5ik2o
17
10k
セキュリティのためのソフトウェア設計について
j5ik2o
4
1.9k
Other Decks in Programming
See All in Programming
Jakarta EE meets AI
ivargrimstad
0
220
初めてDefinitelyTypedにPRを出した話
syumai
0
420
watsonx.ai Dojo #4 生成AIを使ったアプリ開発、応用編
oniak3ibm
PRO
1
140
ピラミッド、アイスクリームコーン、SMURF: 自動テストの最適バランスを求めて / Pyramid Ice-Cream-Cone and SMURF
twada
PRO
10
1.3k
AWS Lambdaから始まった Serverlessの「熱」とキャリアパス / It started with AWS Lambda Serverless “fever” and career path
seike460
PRO
1
260
タクシーアプリ『GO』のリアルタイムデータ分析基盤における機械学習サービスの活用
mot_techtalk
4
1.5k
광고 소재 심사 과정에 AI를 도입하여 광고 서비스 생산성 향상시키기
kakao
PRO
0
170
Less waste, more joy, and a lot more green: How Quarkus makes Java better
hollycummins
0
100
Amazon Bedrock Agentsを用いてアプリ開発してみた!
har1101
0
340
Outline View in SwiftUI
1024jp
1
330
ペアーズにおけるAmazon Bedrockを⽤いた障害対応⽀援 ⽣成AIツールの導⼊事例 @ 20241115配信AWSウェビナー登壇
fukubaka0825
6
2k
Laravel や Symfony で手っ取り早く OpenAPI のドキュメントを作成する
azuki
2
120
Featured
See All Featured
Speed Design
sergeychernyshev
25
620
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
Gamification - CAS2011
davidbonilla
80
5k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
0
100
Typedesign – Prime Four
hannesfritz
40
2.4k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Art, The Web, and Tiny UX
lynnandtonic
297
20k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
42
9.2k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Building Your Own Lightsaber
phodgson
103
6.1k
Designing for humans not robots
tammielis
250
25k
Agile that works and the tools we love
rasmusluckow
327
21k
Transcript
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 ご清聴ありがとうございました!
None