Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a 2022_sakura-yube_ddd.pdf
Semelhante a 2022_sakura-yube_ddd.pdf (20)
2022_sakura-yube_ddd.pdf
- 1. (C) Copyright 1996-2022 SAKURA Internet Inc オブジェクトストレージ開発における DDD（ドメイン駆動設計） ―― DDDの実践 クラウド事業本部＞ クラウドサービス部＞ サービス開発 川井 俊輝 さくらインターネット株 式会社 2022/07/27
- 2. 自己紹介 • 氏名： 川井俊輝（カワイトシキ） • 所属： ─ クラウド事業本部 ─ クラウドサービス部 ─ サービス開発 • 担当： ─ オブジェクトストレージ バックエンド開発 ─ その他 色々 • プライベート： ─ Twitter： @asya_aoi1049 2
- 4. DDD（ドメイン駆動設計）のよくある誤解 DDDという言葉を検索して、こんな書き込みを見たことはありませんか？？ • エンジニアはドメインエキスパートの通訳者だ • レイヤー構造を持ち込めばDDDになる • DDDの構成要素（後述）を全て利用しなければいけない • データの詰替作業がとてもツラい 4
- 5. DDDの基礎 • ドメインとは何か ─ ユーザの何らかの活動や関心や、プログラムを適用するそれらの対象領域 ➢参考： エリック・エヴァンスのドメイン駆動設計p.2 ➢参考： ドメイン駆動設計入門p.2 • DDDとは何か ─ ドメインエキスパートの頭の中にある知識を厳密に構成し抽象化したドメインモデルをイテレーテ ィブに深化させ、ドメインの複雑さに立ち向かうと共にソフトウェアプロダクトを成功させるため の、設計思想または哲学 ➢参考： DDD難民に捧げるDomain-Driven Designのエッセンス ➢※ ソフトウェアプロダクトの成功には、ソフトウェアの品質を高めることも当然含まれる • 参考： 実践ドメイン駆動設計p.1 5
- 6. DDDの基礎 • DDDの前提条件 ─ 開発がイテレーティブであること ─ 開発者とドメインエキスパートが密接に関わっていること ➢参考： エリック・エヴァンスのドメイン駆動設計 序文 • ドメインモデリングとは何か ─ ドメインモデルとは「業務領域（ドメイン）への考え方（捉え方）」であることから ─ 現実の対象領域の概要を表現したものであり ─ そのストーリーを伝達または意見を主張するもの ➢参考： エリック・エヴァンスのドメイン駆動設計 pp.3-5 6 ドメイン ドメインモデル ソフトウェア 解決 ドメインへの理 解と継続的モデ ル改善 ドメインモデル に基づいたソフ トウェアの実装 参考：ドメイン駆動設計は何を解決しようとしているのか
- 7. DDDの基礎 • ドメインモデルの基本用法（ドメインモデルを用いる理由） ─ 知識の蒸留 ➢ドメインエキスパートと議論を重ね、問題の核心を突いたドメインモデルを生成することで、ド メインをどのように考えどのように関心を分離したかを明確にする ─ ユビキタス言語の生成 ➢ドメインエキスパートやその他ステークホルダーが理解可能な共通言語を用い、ドメインモデル のセマンティクスを実装に反映することで、ドメインモデルによって相互コミュニケーションを 行うと共にドメインモデルと実装をきちんと結びつける ─ 実装の早期理解 ➢ドメインモデルと実装がきちんと結びつくことで、効果的な実装を支えると共にドメインについ ての知識を抽象化する 7
- 8. DDDのよくある誤解に対する回答 • 誤解 ─ エンジニアはドメインエキスパートの通訳者だ • 回答 ─ ドメインモデルによってエンジニアとドメインエキスパート（及びステークホルダー）は相互コミ ュニケーションを行う ➢参考： Domain Modeling Made Functional p.5 8 ドメインエキスパート エンジニア コード ソフトウェア フィードバック その他 ステークホルダー エンジニア コード その他 ステークホルダー ドメインエキスパート 共有メンタルモデル （ドメインモデル）
- 9. DDDの基礎 • DDDを成すモデル駆動設計の構成要素 ─ ドメイン層の分離 ➢レイヤードアーキテクチャ ─ ソフトウェアによるドメインモデルの表現 ➢エンティティ ➢値オブジェクト ➢サービス ➢モジュール（パッケージ） ─ ドメインオブジェクトのライフサイクル ➢集約 ➢ファクトリ ➢リポジトリ 9 モデル駆動設計 利口なUI レイヤードアー キテクチャ エンティティ 値オブジェクト サービス パッケージ 集約 ファクトリ リポジトリ
- 10. DDDのよくある誤解に対する回答 • 誤解 ─ レイヤー構造を持ち込めばDDDになる • 回答 ─ ユーザインターフェースやデータベースを操作するコードをビジネスロジックを扱うためのドメイ ン層から分離してはじめて、モデル駆動開発が可能になる ➢参考： エリック・エヴァンスのドメイン駆動設計p.68 ─ つまり、レイヤー構造などを用いて関心・責務を分離することは モデル駆動開発の土台であると いうこと 10
- 11. DDDの基礎 用語の整理 • エンティティ（参照オブジェクト） ─ 連続性や同一性（identity）によって一意性（同一性）を示すためのオブジェクト ➢参考： エリック・エヴァンスのドメイン駆動設計pp.87-94 • 値オブジェクト ─ システム固有の値を表現するためのオブジェクトまたは型 ➢参考： ドメイン駆動設計入門p.16 ─ 値とは一意性を持たないことを意味する ➢参考： 実践ドメイン駆動設計pp.213-216 ─ オブジェクト間のメッセージ転送におけるパラメータやエンティティの属性としても扱われる ➢参考： エリック・エヴァンスのドメイン駆動設計p.97 11 用語の整理のため簡素な説明に留めます
- 12. DDDの基礎 用語の整理 • サービス ─ エンティティや値オブジェクトに責務を持たせることができない操作を、独立したインターフェー スとモデルで定義 ➢参考： ドメイン駆動設計入門pp.66-67 ➢エリック・エヴァンスのドメイン駆動設計pp.103-pp.107 ─ ドメインモデルのクライアントであるアプリケーションサービスと混同しないこと ➢参考： 実践ドメイン駆動設計pp.255-257 • モジュール ─ システムに関する一連の物語の中で１つの概念を凝集した集合 ➢参考： エリック・エヴァンスのドメイン駆動設計pp.108-109 12 用語の整理のため簡素な説明に留めます
- 13. DDDの基礎 用語の整理 • 集約 ─ 関連するドメインオブジェクトの集まりであり、単一のトランザクションで整合性が保たれなけれ ばならない ➢参考： エリック・エヴァンスのドメイン駆動設計pp.124-127 ➢参考： 実践ドメイン駆動設計pp.340-366 ─ つまり不変条件が維持されるべき範囲が集約によって示される • ファクトリ ─ 集約の生成やそれ自体が複雑になる場合、これをカプセル化するインターフェース ➢参考： エリック・エヴァンスのドメイン駆動設計pp.134-136 13 用語の整理のため簡素な説明に留めます
- 14. DDDの基礎 用語の整理 • リポジトリ ─ データ永続化のためにDB等への書き込みや、外部API呼び出しといった操作を抽象化するためのイ ンターフェース ➢参考： ドメイン駆動設計入門p.84 ➢参考： エリック・エヴァンスのドメイン駆動設計p.151 14 用語の整理のため簡素な説明に留めます
- 15. DDDのよくある誤解に対する回答 • 誤解 ─ DDDの構成要素（後述）を全て利用しなければいけない ─ データの詰替作業がとてもツラい • 回答 ─ サービス、モジュールは責務や概念を分離する必要がある場合にのみ利用する ─ ファクトリは集約の生成が複雑になった場合にのみ利用する ─ 責務や概念の分離が必要だからレイヤーがあり、データの詰替作業が発生する ─ 不要なレイヤーを設けていないか、そもそもドメインモデルの設計が正しいか確認する 15
- 16. オブジェクトストレージにおけるDDDのプロセス • ビジネスイベントを介したドメインの理解 ─ ビジネスはデータの変換の連続と捉える • ユビキタス言語の定義 ─ ドメインエキスパートとステークホルダーとの共通言語を持つ • ドメインを自然言語で定義 ─ 最もシンプルなテキストベースによって ─ ドメインコンテキストやフローを定義 • ドメインモデルの深化 ─ ドメインの重要な箇所を明確にすると共に ─ 不要な部分を取り除く Domain Modeling Made Functional を参考にした。 16 ドメインの理解 ユビキタス言語 の定義 ドメインのドキ ュメント化 ドメインモデル の深化
- 17. 登場人物 ドメイン エキスパート エンジニアA エンジニアB 企画 エンジニアC ステークホルダー 開発チーム インフラチーム • 当社におけるオブジェクトストレージのサービスは幅 広いステークホルダーが存在する • 各チームから開発フェーズに応じてメンバーがアサイ ンされる • 運用フェーズをコアメンバーで行っている
- 18. オブジェクトストレージにおけるDDDのプロセス • ビジネスイベントを介したドメインの理解 ─ ビジネスはデータの変換の連続と捉える • ユビキタス言語の定義 ─ ドメインエキスパートとステークホルダーとの共通言語を持つ • ドメインを自然言語で定義 ─ 最もシンプルなテキストベースによって ─ ドメインコンテキストやフローを定義 • ドメインモデルの深化 ─ ドメインの重要な箇所を明確にすると共に ─ 不要な部分を取り除く Domain Modeling Made Functional を参考にした。 18 ドメインの理解 ユビキタス言語 の定義 ドメインのドキ ュメント化 ドメインモデル の深化
- 19. ビジネスイベントを介したドメインの理解 • さくらのオブジェクトストレージAPI を参考に進める • 下記についてドメインエキスパートを含むステークホルダーと議論し整理する • オブジェクトストレージの機能 ─ サイト選択 ─ サイトアカウント作成・削除 ─ バケット作成・削除 ─ アクセスキー発行・削除 ─ パーミッション作成・削除 ─ パーミッションキー発行・削除 19
- 20. ビジネスイベントを介したドメインの理解 ※ オブジェクトストレージでは明確に誰がドメインエキスパートであるか、は定められていないが、説 明のためにドメインエキスパートと表記する ※ 私がアサインされた際にDDDを意識していなかったが、以下のようなやり取りを行った • エンジニアA「ユーザが弊社オブジェクトストレージを利用しバケットを作成したい、というビジネ スイベントが発生したとして、弊社オブジェクトストレージを利用するためのトリガーは何ですか」 • ドメインエキスパート「まず前提としてクラウドコンパネにログインし、サイトを選択する必要があ ります」 • エンジニアB「サイトとは何ですか」 • ドメインエキスパート「サイトはバケット等を格納する物理的位置で、弊社で言えばゾーン、 Amazon S3で言えばリージョンに相当するでしょう」 20 クラウドコン パネ ログイ ン サイト選択
- 21. ビジネスイベントを介したドメインの理解 • エンジニアA「サイトを選択した後、すぐにバケットを作成できるのですか」 • ドメインエキスパート「サイトに紐づくアカウント（サイトアカウント）を作成しておく必要があり ます。サイトアカウントはクラウド側の契約と紐づけるために存在しています」 • エンジニアB「サイトアカウントがバケットを所有するのですね」 • ドメインエキスパート「はい、そうです」 21 クラウドコン パネ ログイ ン サイト選択 サイトアカウ ント作成
- 22. ビジネスイベントを介したドメインの理解 • エンジニアA「サイトアカウント作成後にバケットを作成できるのですか」 • ドメインエキスパート「はい。オブジェクトストレージ コンパネではサイトアカウント作成に際して、 同時にアクセスキーも発行しています」 • エンジニアB「アクセスキーの作成は必須なのですか」 • ドメインエキスパート「コンパネではそのようにしています」 22 クラウドコン パネ ログイ ン サイト選択 サイトアカウ ント作成 アクセスキー 発行 バケット作成
- 23. ビジネスイベントを介したドメインの理解 • エンジニアA「ところで、バケットにはどのような制約がありますか」 • ドメインエキスパート「バケット名はオブジェクトストレージ全体で一意である必要があります」 • エンジニアB「なるほど。サイトを跨いで同じ名前のバケットを作成できない、ということですね」 • ドメインエキスパート「はい、そうなります。それ以外にもオブジェクトストレージ全体で制約を加 えたいものはいくつかありますね」 23 クラウドコン パネ ログイ ン サイト選択 サイトアカウ ント作成 アクセスキー 発行 バケット作成 オブジェクトス トレージ全体を 一意に管理
- 25. ビジネスイベントを介したドメインの理解 • 境界づけられたコンテキスト ─ ドメインモデルを適用できる範囲を限定したもの ➢参考： エリック・エヴァンスのドメイン駆動設計pp.334-345 ➢参考： 実践ドメイン駆動設計 第2章 ─ 「境界づけられたコンテキスト not eq モジュール」に留意 25 クラウドコン パネ ログイ ン サイト選択 サイトアカウ ント作成 アクセスキー 発行 バケット作成 パーミッショ ン作成 パーミッショ ンキー発行 オブジェクトス トレージ全体を 一意に管理
- 26. ビジネスイベントを介したドメインの理解 • 境界づけられたコンテキスト ─ Federation ─ Site • コンテキストマップ（省略） 26 クラウドコン パネ ログイン サイト選択 サイトアカウ ント作成 アクセスキー 発行 バケット作成 パーミッショ ン作成 パーミッショ ンキー発行 オブジェクトス トレージ全体を 一意に管理 Federation Site
- 27. オブジェクトストレージにおけるDDDのプロセス • ビジネスイベントを介したドメインの理解 ─ ビジネスはデータの変換の連続と捉える • ユビキタス言語の定義 ─ ドメインエキスパートとステークホルダーとの共通言語を持つ • ドメインを自然言語で定義 ─ 最もシンプルなテキストベースによって ─ ドメインコンテキストやフローを定義 • ドメインモデルの深化 ─ ドメインの重要な箇所を明確にすると共に ─ 不要な部分を取り除く Domain Modeling Made Functional を参考にした。 27 ドメインの理解 ユビキタス言語 の定義 ドメインのドキ ュメント化 ドメインモデル の深化
- 28. ユビキタス言語の定義 ※ 私がアサインされた後にユビキタス言語またはそれに相当するものに関する、以下のようなやり取り を行った • 企画「クラスタの追加計画は20○○年ごろに予定しています」 • エンジニアB「クラスタとはk8sのことを指していますか？それともコンパネで表示される“石狩第1” のような物理的位置を指していますか？」 • 企画「今回は後者ですが、分かりづらいですね…」 • エンジニアA「オブジェクトストレージでは バックエンドの基盤としてk8sを利用しており、私たち はこれをクラスタと呼んでいます。さらに、オブジェクトストレージの基盤のハードウェア群もクラ スタと呼んでいて、混乱してしまいます。」 • エンジニアC「では、オブジェクトストレージの物理的位置を示す言葉は“サイト”にするのはどうでし ょうか？」 • 一同「いいですね！それにしましょう」 • ドメインエキスパート「いいですね、OKです」 28
- 29. ユビキタス言語の定義 • 前述のやり取り等を経て、オブジェクトストレージチーム内で全員が共通認識を持てる用語（ユビキ タス言語）を定め、これを表に示した • その後、定めたユビキタス言語に従って、コンテキストやドメイン・サブドメインの名称を修正した • また、オブジェクトストレージは複数の小さなチームから構成されるため、各チームで利用する用語 も合わせて記載した 29 No. 公開 和名 英名 意味 利用チーム 1 ○ サイト Site オブジェクトストレ ージの物理的位置 全体 2 ○ ユーザ User オブジェクトストレ ージの利用者 全体 3 ☓ XXXX XXXX XXXX インフラチーム 4 ☓ Kubernetesクラス ター Kubernetes Cluster バックエンドAPI等 を稼働させるクラス タ 開発チーム … … … … … …
- 30. オブジェクトストレージにおけるDDDのプロセス • ビジネスイベントを介したドメインの理解 ─ ビジネスはデータの変換の連続と捉える • ユビキタス言語の定義 ─ ドメインエキスパートとステークホルダーとの共通言語を持つ • ドメインを自然言語で定義 ─ 最もシンプルなテキストベースによって ─ ドメインコンテキストやフローを定義 • ドメインモデルの深化 ─ ドメインの重要な箇所を明確にすると共に ─ 不要な部分を取り除く Domain Modeling Made Functional を参考にした。 30 ドメインの理解 ユビキタス言語 の定義 ドメインのドキ ュメント化 ドメインモデル の深化
- 31. ドメインを自然言語で定義 • 今日のハイライト ─ ドメイン、境界づけられたコンテキスト、コンテキストマップ、ユビキタス言語が定まると、私達 エンジニアはすぐにコードに落とし込みたくなる ─ いくつかの書籍や私の経験から見ても、１度の議論でドメインやコンテキストを正確に捉えること は困難 ─ UMLやそれに準ずるツールである PlantUML で書いても良いが、表記の意味やツールの使い方の 学習が必要… ─ まずは自然言語または擬似的なプログラミング風のミニ言語でドメインを定義する ➢参考： Domain Modeling Made Functional Chapter.2 ─ ステークホルダー全員が理解できる（しやすい）ため ※ 仮にチームやステークホルダーがUMLへの理解を持ち合わせている場合は、ドメイン駆動設計の２つのモデリング手法 ユースケース図とドメ インモデル図をどう作る？ を参照されたい 31
- 32. ドメインを自然言語で定義 バケット作成を例にあげる • 境界づけられたコンテキスト ─ Federation • ワークフロー ─ トリガー ➢オブジェクトストレージコンパネからのバケット作成要求 ─ 入力 ➢バケット名 ➢さくらのクラウドアカウントに関するパラメータ（省略） ─ 出力 ➢バケット名 ➢サイトID 32 Federation Site
- 33. ドメインを自然言語で定義 バケット作成を例にあげる • 境界づけられたコンテキスト ─ Site • ワークフロー ─ トリガー ➢Federation からバケットの作成要求 ─ 入力 ➢バケット名 ➢さくらのクラウドアカウントに関するパラメータ（省略） ─ 出力 ➢バケット名 33 Federation Site
- 34. ドメインを自然言語で定義 バケット作成におけるデータ構造はどうか • 境界づけられたコンテキスト ─ Federation • データ構造 ─ バケット ➢Name ➢SiteID // isk01 ➢State // Created or Deleted • 副作用 ─ ??? // Don’t know yet ※ 副作用とは、本来の目的に伴って発生する変化や、本来の目的以外を変化させること 34 Federation Site Federationコンテキストに副作用が含まれるかは、 この時点では不明。 １度のコミュニケーションでは全てを把握できない
- 35. ドメインを自然言語で定義 バケット作成におけるデータ構造はどうか • 境界づけられたコンテキスト ─ Site • データ構造 ─ バケット ➢??? // Don’t know yet ➢Name ➢State // Created or Creating or Deleted • 副作用 ─ ??? // Don’t know yet 35 Federation Site Siteコンテキストに副作用が含まれるかは、この時 点では不明。 Siteコンテキストに副作用が含まれるかは、この時 点では不明。
- 36. ドメインを自然言語で定義 ワークフローやデータ構造で不明な点をドメインエキスパートと協力しながら明らかにしていく • エンジニアA「SiteコンテキストまたはFederationコンテキストにおいて、副作用は発生しますか」 • ドメインエキスパート「はい。弊社オブジェクトストレージはバケット毎に基本料金が発生する仕様 です。そのため、バケット作成のタイミングで課金システムが料金計算できるようにリソースIDの登 録が必要です」 • エンジニアB「バケット作成を行うのはSiteコンテキスト側であるため、こちらに副作用を持たせるの が良さそうです」 36
- 37. ドメインを自然言語で定義 バケット作成におけるデータ構造 • 境界づけられたコンテキスト ─ Federation • データ構造 ─ バケット ➢Name ➢ClusterID // isk01 ➢State // Created or Deleted • 副作用 ─ なし ??? // Don’t know yet 37 Federation Site 課金システム 当初分からなかった副作用が判明した
- 38. ドメインを自然言語で定義 バケット作成におけるデータ構造 • 境界づけられたコンテキスト ─ Site • データ構造 ─ バケット ➢リソースID ??? // Don’t know yet ➢Name ➢State // Created or Creating or Deleted • 副作用 ─ バケット基本料金を計算できるよう課金システムが判別可能なリソースIDを登録する ??? // Don’t know yet 38 Federation Site 課金システム 当初分からなかった副作用が判明した
- 39. ドメインを自然言語で定義 • 前述の内容は 詳細な部分の大半を省略している。 • 実際には、認証情報の確認、入力されたバケット名がすでに存在するかどうかの確認、命名規則に従 っているか等をチェックするステップが組み込まれている • ワークフローに上記のステップを組み込むことで、ステークホルダーが処理の流れを理解することを 助ける • ミニ言語での定義については https://github.com/Asya-kawai/mail-chat/wiki を参照して下さい 39
- 40. オブジェクトストレージにおけるDDDのプロセス • ビジネスイベントを介したドメインの理解 ─ ビジネスはデータの変換の連続と捉える • ユビキタス言語の定義 ─ ドメインエキスパートとステークホルダーとの共通言語を持つ • ドメインを自然言語で定義 ─ 最もシンプルなテキストベースによって ─ ドメインコンテキストやフローを定義 • ドメインモデルの深化 ─ ドメインの重要な箇所を明確にすると共に ─ 不要な部分を取り除く Domain Modeling Made Functional を参考にした。 40 ドメインの理解 ユビキタス言語 の定義 ドメインのドキ ュメント化 ドメインモデル の深化
- 42. オブジェクトストレージにおけるDDDのプロセス＋ • ドメインモデル作成後は実装するだけだが、具体的には入力、出力、副作用に応じてレイヤ構造にマ ッピングする • マッピングやレイヤ毎の関心・責務の分離は、インターネットの多くの記事で詳細に扱われているた め説明は割愛する。 42 Domain API/Interface Service Database Infrastructure 引用： Domain Modeling Made Functional p.54 Workflow
- 43. まとめ • DDDとはドメインモデルを捉えた上で、それをコードに落とし込む設計思想 • DDDや関連する書籍で紹介されているテクニックだけを用いても、ドメインを正確に捉えることはで きない • ドメインのコンテキスト及びコンテキスマッピングを捉える戦略的設計と、ドメイン内部をモデリン グする戦術的設計の両方を用いる必要がある • DDDはそのプロセスの中でドメインエキスパート及びステークホルダーと協調してドメインモデルを 深化させ、ビジネスの変化に適応する必要がある 43
- 44. 参考文献 • エリック・エヴァンスのドメイン駆動設計 • 実践ドメイン駆動設計 • ドメイン駆動設計入門 • Domain Modeling Made Functional • A Philosophy of Software Design • Domain-Driven Designのエッセンス 44