$30 off During Our Annual Pro Sale. View Details »

Learning Domain-Driven Design Round-reading session 3

Learning Domain-Driven Design Round-reading session 3

『Learning Domain-Driven Design』 輪読会 No.3 の資料です。

## イベント
https://showcase-gig.connpass.com/event/245123/

Daisuke Sato

April 21, 2022
Tweet

More Decks by Daisuke Sato

Other Decks in Technology

Transcript

  1. Learning Domain-Driven Design 輪読会 No.3 Chapter 2. Discovering Domain Knowledge/ドメイン知識の発見

    https://showcase-gig.connpass.com/event/245123/ 2022/04/21 daisuke.sato @dskst9
  2. 注意 本資料は、書籍『Learning Domain-Driven Design』のChapter2 を意訳・要約したものです。 資料に記載の内容は、 @dskst9 が解 釈した内容であり、原文の表現や内容と は異なるものも含まれています。

  3. Chapter 2. Discovering Domain Knowledge 2-1. Business Problems/ビジネス課題 2-2. Knowledge

    Discovery/ナレッジ発見 2-3. Communication/コミュニケーション 2-4. What is a Ubiquitous Language?/ユビキタス言語とは? 2-5. Language of the Business/ビジネスの言語 2-6. Model of the business domain/ビジネスドメインのモデル 2-7. Conclusion/結論 2-8. Exercise/エクササイズ
  4. It's developers' (mis)understanding, not domain experts' knowledge, that gets released

    in production. -Alberto Brandolini 製品としてリリースされるのは、開発者の(誤った)理解であって、ドメインエキスパートの 知識ではない。
  5. aaa この章では、ビジネスドメイン分析の深さについて説明する。サブドメインの内 部で何が起こっているのか、そのビジネス機能とロジックに焦点を当てる。 ビジネスドメインの複雑さを学ぶために、効果的なコミュニケーションと知識共 有ためのドメイン駆動型設計ツールである「ユビキタス言語」を使用する。 Overview

  6. 2-1. Business Problems /ビジネス課題

  7. ソフトウェアは、ビジネス上の問題に対する解決策となる。ビジネス上の問題に は以下のようなものがあり、ビジネスドメインレベルとサブドメインレベルの両 方で発生する。 • ワークフローやプロセスの最適化 • 手作業の最小化 • リソースの管理 •

    意思決定の支援 • etc 2-1. Business Problems
  8. サブドメインは、特定のビジネス能力に対するソリューションを提供することを 目的とした、より細かい問題領域である。 • 知識管理のサブドメインは、情報の保存と取り出しのプロセスを最適化す る。 • 清算のサブドメインは、金融取引のプロセスを最適化する。 • 会計サブドメインは、会社の資金を追跡する。 2-1.

    Business Problems
  9. 2-2. Knowledge Discovery /ナレッジ発見

  10. 効果的なソフトウェアを設計するためには、少なくともビジネスドメインの基本 的な知識を把握する必要がある。 • ビジネスドメインの複雑な部分を全て専門的に理解するのがドメインエキ スパートの仕事 • エンジニアは決してドメインエキスパートになるべきではないし、なることも できない。ドメインエキスパートを理解し、彼らが使うビジネス用語と同じも のを使うことが重要 2-2.

    Knowledge Discovery
  11. 専門家のメンタルモデル を模倣する 2-2. Knowledge Discovery 効果的なソフトウェアにするために は、専門家の問題に対する考え方 (メンタルモデル)を模倣する必要が ある。 ビジネス上の問題や要求の背後に

    ある理由を理解しなければ、ソリュー ションはビジネス要件をソースコード に「翻訳」することにとどまってしま う。
  12. ソフトウェアは学習プロ セスである 2-2. Knowledge Discovery ソフトウェアは学習プロセスであり、ソ フトウェアの成功は専門家とエンジニ アの知識共有の効果に依存する。 問題を解決するためには、問題を理 解しなければならない。知識を共有

    するにはコミュニケーションが必要。
  13. 2-3. Communication /コミュニケーション

  14. 効果的なコミュニケーションは、知識 の共有とプロジェクトの成功に不可 欠。 多くの場合、ビジネスパーソンとエン ジニアが直接交流することはなく、そ の知識はプロダクトオーナーなど仲介 役となる人たちを通じて伝達される。 2-3. Communication 出典:

    Learning Domain-Driven Design
  15. ドメイン知識をエンジニアに優しい言 葉に「翻訳」すると、背後にあるビジネ スドメインの理解ができなくなる。 ドメイン知識を①分析モデルへ翻訳、②ソフト ウェア設計書へ翻訳、③実装モデルへ翻訳、 ④ソースコードへ翻訳するとビジネス情報が 失われていく。 2-3. Communication 出典:

    Learning Domain-Driven Design
  16. ドメイン駆動設計では、 ユビキタス言語を使うことで、ドメ インエキスパートからエンジニアに 知識を伝える 2-3. Communication

  17. 2-4. What is a Ubiquitous Language? /ユビキタス言語とは?

  18. 従来のソフトウェア開発ライフサイク ルでは、右記のような変換をしてい る。 継続的に変換する代わりに、ビジネス を説明するための単一言語であるユ ビキタス言語を育成する。 • ドメイン知識を分析モデルへ • 分析モデルを要求へ

    • 要求事項をシステム設計へ • システム設計をソースコードへ 2-4. What is a Ubiquitous Language?
  19. すべてのステークホルダーが、翻訳に頼るのではなくユビキタス言語を話し、 記述しなければならない。 ドメインエキスパートが、ビジネスドメインについて推論をする際に、ユビキタス 言語を快適に使用できることが重要。ビジネスドメインとドメインエキスパートの メンタルモデルの両方を表現する。 2-4. What is a Ubiquitous

    Language?
  20. 2-5. Language of the Business /ビジネスの言語

  21. ユビキタス言語は、ビジネスの言語である。ビジネス領域に関連する用語のみ で構成される必要がある。(技術的な専門用語は使わない) ユビキタス言語の目的は、ドメインエキスパートのビジネス知識とメンタルモデ ルを、理解しやすい言葉にすること。 2-5. Language of the Business

  22. ビジネスの言葉で作成されたステートメント。 1. 広告キャンペーンでは、さまざまなクリエ イティブな素材を表示できます。 2. キャンペーンは、そのプレースメントの少 なくとも1つがアクティブである場合にのみ 公開できます。 3. 販売手数料は、取引が承認された後に会

    計処理されます。 2-5. Language of the Business - Senarios 技術的な言葉で作成されたステートメント。 1. 広告フレームには、HTMLファイルが表示 されます。 2. キャンペーンは、active-placements テーブルに少なくとも 1つの関連レコード がある場合にのみ公開できます。 3. 販売手数料は、取引テーブルと承認済み 販売テーブルの相関レコードに基づいて います。
  23. 2-5. Language of the Business - Senarios 技術的な言葉で作成されたステートメント。 1. 広告フレームには、

    HTMLファイルが表示されま す。 2. キャンペーンは、active-placements テーブ ルに少なくとも1つの関連レコードがある場合に のみ公開できます。 3. 販売手数料は、取引テーブルと承認済み販売 テーブルの相関レコードに基づいています。 技術的な言葉は、ドメインエキ スパートにとっては不明瞭なも のであり、エンジニアもビジネ スロジックを完全には理解でき ない。
  24. ユビキタス言語は、正確で一貫している必要がある。ユビキタス言語の各用語 は1つだけの意味を持つ。 2-5. Language of the Business - Consistency 曖昧な用語

    たとえば、「ポリシー」という用語は、規制規則また は保険契約を意味する場合がある。正確な意味 は、文脈に応じて人間同士で相互理解ができる が、ソフトウェアは曖昧さを理解できない。 同義語 たとえば、「ユーザー」という用語は、訪問者、管理 者、アカウントなどの他の用語と同じ意味で使われ ていることがある。特定のコンテクストにおいて各 用語を明示的に使用することで、用語の違いを理 解でき、単純で明確なモデルと実装を構築すること ができる。
  25. 2-6. Modelof the Business Domain /ビジネスドメインのモデル

  26. モデルとは、あるものや現象を、ある面を意図的に強調し、他の面を無視して 簡略して表現したもの。特定の用途を想定して抽象化したもの。 モデルは現実世界のコピーではなく、現実世界のシステムを理解するのに役 立つ人間の構成物である。 2-6. Model of the Business Domain

  27. モデルの典型例として、地図がある。 どの地図もモデルであり、ナビゲーショ ン、地形、地下鉄などを表している。そ れぞれのモデルで、特定の目的や解決 したい問題をサポートするのに十分な データが含まれている。 2-6. Model of the

    Business Domain 出典: Learning Domain-Driven Design
  28. Effective Modeling 効果的なモデルには、その目的を達成するために必要な詳細のみが含まれて いる。本質的にはモデルは抽象化であり、不要な詳細を省略する。問題を解 決するために必要なものだけを残すことで、複雑さを処理する。 2-6. Model of the Business

    Domain
  29. Modeling the Business Domain ビジネスドメインのモデルを効果的に構築するには、関与する事業体とその行 動、因果関係、及び不変条件を反映する。必要なシステムの実装を可能にす るのに十分なビジネスドメインの側面が含まれている。 ソフトウェアが解決しようとしている特定の問題に対処するため、ドメインのす べてを網羅することは想定しない。 2-6.

    Model of the Business Domain
  30. Continuous Effort ユビキタス言語は、ドメインエキスパートとのやり取りによって、不正確さや欠 陥のある箇所を明らかにすることができる。 ユビキタス言語の育成は継続的なプロセスとなる。要件、ドキュメント、ソース コードもユビキタス言語を使用する。日常的に使用することで、ビジネスドメイ ンに対するより深い洞察が可能になる。 2-6. Model of

    the Business Domain
  31. Tool ユビキタス言語の管理プロセスを軽減できるツールやテクノロジーがある。たと えば、Wikiはユビキタス言語を文書化するための用語集として使用できる。用 語集は全てのチームメンバーが更新する。 2-6. Model of the Business Domain

  32. Tool 「名詞」も大事だが、行動を捉えることが非常に 重要。動詞に関連づけられたただのリストでは なく、ルール、仮定、及び不変条件を含むビジ ネスロジックがある。これは用語集では表現し にくい。 ユースケースやGherkin言語で書かれたテスト コードは、ユビキタス言語をキャプチャできる。 ndependでは、ユビキタス言語を静的解析でき る。

    2-6. Model of the Business Domain 出典: Learning Domain-Driven Design
  33. プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 出典: アジャイルソフトウェア開発宣言

  34. Challenges ドメイン知識を収集する唯一の信頼できる方法は、ドメインエキスパートと会話 すること。多くの場合、最も重要な知識は暗黙知にある。 ドメインエキスパート自身のビジネスドメインの理解にも、曖昧さや明示的な定 義がないものもある。学習プロセスは相互のものであり、ドメインエキスパート が自分たちのビジネスドメインをよりよく理解する助けになる。 2-6. Model of the

    Business Domain
  35. • ソフトウェアプロジェクトの成功には、効果的なコミュニケーションと知識の 共有が不可欠。 • エンジニアはビジネスドメインを理解する必要がある。 • ユビキタス言語は、ドメインエキスパートとの知識ギャップを埋めるための 効果的なツールである。 • ユビキタス言語の育成は、継続的なプロセスになる。

    • Wikiなどのツールを利用すると、管理プロセスを軽減できる。 2-8. Conclusion
  36. Exercises ユビキタス言語の定義に貢献できるのは誰か? 1. ドメインエキスパート 2. ソフトウェアエンジニア 3. エンドユーザー 4. プロジェクトのすべてのステークホルダー

  37. Exercises ユビキタス言語はどこで使われるべきか? 1. 対面での会話 2. ドキュメンテーション 3. コード 4. 上記全て

  38. Exercises 序文にある架空の会社「WolfDesk」の説明文をご覧ください。その説明の中に、 どのようなビジネス領域の用語がありますか?

  39. Exercises 現在取り組んでいる、あるいは過去に取り組んだソフトウェアプロジェクトを考え てみましょう。 1. ドメインエキスパートとの会話に使えるようなビジネスドメインの概念を考え てみてください。 2. ビジネスドメインのコンセプトが異なる意味を持つ、あるいは同じコンセプト が異なる用語で表現されているなど、一貫性のない用語の例を挙げてみてくだ さい。

    3. コミュニケーション不足から生じたソフトウェア開発の非効率性に遭遇したこ とがありますか?
  40. Exercises プロジェクトに参加しているとき、異なる組織単位の専門家が、ビジネスドメイン の無関係な概念を表現するために同じ用語、例えばpolicyを使用していることに 気づいたとします。 その結果、ユビキタス言語は、ドメインエキスパートのメンタルモデルに基づいて いるが、用語が単一の意味を持つという要件を満たすことができない。 次の章に進む前に、このような難問にどのように対処しますか?

  41. Thank you for listening