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

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

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

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

かとじゅん
PRO

September 24, 2019
Tweet

More Decks by かとじゅん

Other Decks in Programming

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  6. © Chatwork
    いきなりドメインモデルを考えれるか
    ● 初見だと無理に近い。ドメインモデルの目的と
    か背景がわからないと考えられない(当然
    ● ドメインモデルには抽象化のための選択と集中
    がある。こういった戦略をどこから導けばよい
    か?
    ● ドメインモデル自体は導かれた結果なので、ド
    メインモデルの外側に目を向けなければならな

    ● ブログ記事:ドメインモデルの根拠とドメインモ
    デル貧血症の対策について

    View Slide

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




    業務フロー/
    利用シーン

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  15. © Chatwork
    利用シーン
    ● 利用シーン(汎用的なツールな
    ど)
    ○ システムはどのようなシー
    ンで利用されるか
    ○ 利害関係者との繋がりを示

    ● ユビキタス言語の候補が見つか

    ● リソースオーナー
    ○ クライアントを利用したい
    ■ OAuth2のフローに従いリソース
    オーナーはクライアントに認可を
    与えることができること
    ○ 認可を与えたクライアントを管理した

    ■ 認可を与えたクライアントの一覧
    を管理画面から確認でき、必要で
    あればその認可を失効できること
    OAuthプロジェクトの例

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  22. © Chatwork
    ご清聴ありがとうございました!

    View Slide

  23. View Slide