Help us understand the problem. What is going on with this article?

ユビキタス言語と境界付けられたコンテキストを構築する目的とは

More than 1 year has passed since last update.

このエントリーは、 「ドメイン駆動設計 #1 Advent Calendar 2018」の23日目の記事です。
22日目は、@dnskimo@github さんの「集約とトランザクション境界に関するメモ」でした。

はじめに

この記事は以下の書籍から数多く引用しています。この記事を読んで興味をもたれた方は併せてご覧頂ければと思います。

TL,DR

  • ドメイン駆動設計におけるドメインとは、あるシステムにおける領土・分野のこと
  • ユビキタス言語とは、ある目的に添った、ステークホルダ間での共通理解に必要な言葉の『最も小さな粒度である単語』のこと
  • 境界付けられたコンテキストとは、あるシステム境界におけるドメインにおいて『ユビキタス言語を元に構築された文脈(コンテキスト)』のこと
  • 概念モデルとは、境界付けられたコンテキスト内部でユビキタス言語によって構築される「物事」「考え」「対象」「現象」の本質を抽出して単純化した構造のこと
    • 本質的に全てのモデルは間違っているが、中には役に立つ物もある。 - George E.P. Box

『ソフトウェアの核心にある複雑さに立ち向かう』とは

 ドメイン駆動設計は、Eric Evansが発表したソフトウェア設計と開発に対するアプローチです。同書の副題は、『ソフトウェアの核心にある複雑さに立ち向かう』となっています。さて、ソフトウェアの複雑さとは何を指すのでしょうか?
 筆者にとってのソフトウェアの複雑さとは、ソフトウェア開発を取り巻く周辺環境(プロジェクト管理、設計、実装、運用など)において、
何もしなければ、エントロピー増大の法則により秩序から無秩序へと進んだ先にある、無秩序な状態』であると考えています。
無秩序なソフトウェア開発の現場では、システムを熟知しているエンジニアの退職などで全貌の把握が不可能となったり、品質担保のための管理工数の増大モチベーションの低下コストの増大納期の遅れなどが発生する可能性が高いことが否定できません。
 筆者の考えるドメイン駆動設計の『複雑さに立ち向かう』理由は、ドメイン駆動設計を利用した現場で利用されることの多いアジャイル開発(プロジェクトマネージメント手法)で定義される『予算』『時間』『品質』『スコープ』の4点のトレードオフ要素が、各々トレードオフがありながらも全ての要素が良い方向に向かわせて、結果として秩序立てた状態とすることです。
トレードオフの取捨選択(トレードオフスライダーと呼ばれます)は選択と集中のための手段ですが、プロジェクトを運営する上で『品質』も『スコープ』も『時間』も犠牲にできないという場合(『予算』は外的要因が多いため除外しています)に、可能な限り各要素を最大化を目指す為の手段であると言えます。
 ドメイン駆動設計における『複雑さに立ち向かう』ために必要な要素として、平易で簡潔な言葉で説明が可能となる『ユビキタス言語』と、ユビキタス言語により構築された機能その物である『境界付けられたコンテキスト』を関係者間で築き上げ、全関係者が納得できる形で『概念モデル』を完成することがゴールです。

『ドメイン駆動設計における分析』とは

 ドメイン駆動設計における分析とは、『ユビキタス言語』の構築『境界付けられたコンテキスト』の構築の2点が挙げられます。
 ユビキタス言語とは、ある目的に添った、ステークホルダ間での共通理解に必要な言葉の『最も小さな粒度である単語』です。
たとえば、筆者の本業であるレシピ動画メディアでは、『レシピ(料理)』『キュレーション(配信用レシピのバルクで「本日のオススメ」などの一セット)』『フライヤー(チラシ)』などがその代表例です。
これらの単語は、たまたま自然言語と一致して分かりやすい物となっていますが、組織内でしか通じない言葉となることも希ではありません。
 境界付けられたコンテキストとは、あるシステム境界におけるドメインにおいて『ユビキタス言語を元に構築された文脈(コンテキスト)』です。
境界付けられたコンテキストは、よりドメインの範囲の広いユビキタス言語であり、例えば『リテール(小売り)』や『プレミアム(特別性の高い課金)』などがあげられます。
 実際のビジネスにおけるソフトウェアの利用はビジネスの活動の全体においてその一部であり、ビジネスドメインにおける本質的な関心事はソフトウェアが生み出した成果(売上げなど)を指すことが多く、ソフトウェアそのものには関心が低い場合が多いです。
ソフトウェアエンジニアとしては、ビジネスの専門家がシステムそのものに関心が低い場合があることを理解しながらも、関係者を巻き込んで『ユビキタス言語』と『境界づけられたコンテキスト』の構築を進めることを理解しておく必要があるでしょう。

ユビキタス言語を構築する目的

 Eric Evansは、ソフトウェア開発者がドメインエキスパートやユーザーなどの関係者と会話する場合、いかなる場合においても誤解のリスクを緩和するため共通理解が可能な、なるべく平易で簡潔な言葉(単語)を用いて、システムに関わる関係者間で誤解が発生しないように努めることを推奨しました。
この言葉は共通知識や言語として組織内に浸透することから、ユビキタス[至る所にある、遍在する、至る所に姿を現わす]な言葉となり、ユビキタス言語と呼ばれることとなりました。
 ユビキタス言語は一度決まったらそのままではなく、ドメインに関連する知識が深まるに都度、徐々に変化して進化する可能性があります。もしユビキタス言語の進化が発生した場合は、該当のユビキタス言語を用いたコーディング規約やコードと同期してリファクタリング対象となり、システムへの理解がさらに深まる事につながります
 ユビキタス言語を構築する意義とは、仕様策定の会議体・設計・コードそのものなどの全ておいてに、遍在的に(ユビキタス)に現れることで、組織内の人員のシステムに対する共通理解を深めることが目的です。

境界付けられたコンテキストを構築する目的

 境界付けられたコンテキストとは、システム相互作用における境界が定義された物を指し、実際のプロジェクトでは『縄張り』のような物です。境界付けられたコンテキスト内の各コンテキストはユビキタス言語の一つとして構築されて命名されることになります。
 ビジネスドメイン(ビジネス領域)の世界では、さまざまなサブドメインに比較的簡単に分割されることがありますが、ソフトウェア開発におけるドメインは、機能や概念が重複せずに簡単にサブドメインに分割できるケースは多くありません。
各コンテキストの境界を定義して、その内部のコンテキストがどのように扱うかを、図を書く作業はコンテキストマッピングと呼ばれます。
コンテキストマッピングをすることにより、ビジネスドメインにおける責任範囲の分離に役立つことがあります。本質的にはビジネスドメインとソフトウェア開発のドメインは表裏一体であるのですが、とあるシステムで機能系とレポート系があったときに、機能系はソフトウェアドメインとビジネスドメインを比較的簡単に分離できるのに対して、レポート系はビジネスドメインで分離が難しいことが多いです。
これはレポート系が各ビジネスドメインのデータを集約して、まとめた結果をレポートや帳票として出力する必要があるためです。従ってレポート系は本当に境界づけられたコンテキストとして分離する必要があるのか、よく考慮して設計する必要があります。
 境界付けられたコンテキストにより定義された各コンテキストは、実際の企業内の物理的な組織を反映していることがよくあります。
これはコンウェイの法則と呼ばれており、コンテキスト内部の名前がユビキタス言語となり、ユビキタス言語がチーム名となることがあります。
ソフトウェアは最終的には企業内の組織構造に反映されることから、コンテキストマップに企業の組織図を反映させるべきであるという考えがあります。しかしながら筆者の経験では、コンテキストマップをそのまま企業の組織図に当てはめることはスムーズにいかないことが多く、組織構造の変更がソフトウェアの構造変更よりも苦難が大きいことが原因であると考えられます。
 近年ではコンウェイの法則を逆手に取った、逆コンウェイ戦略と呼ばれる考え方が出現しています。これは組織体にソフトウェアを当てはめるのではなく、逆に戦略的に組織構造をソフトウェアに反映させることで、ビジネスの方向性とシステムの方向性を一致させて組織内コミュニケーションのAgility(俊敏性)を高める戦略です。
従って境界付けられたコンテキストを定義する目的とは、各組織体のチーム編成を適切な設計境界により行うことで、各チームが自分に与えられたコンテキストに『縄張り意識』を持つことが、チーム内外の人員に対する責任感やチーム内の一体感を生み、人と情報の流れを円滑とすることがゴールとなります。
 近年の大規模システムを構築する際によく取られる手法であるマイクロサービスは、境界付けられたコンテキストの境界の定義を適切に進めることで、成功確率が高い大規模サービスを作る手段と言っても差し支えありません。
組織内の文化にもよりますが、一度境界づけられたコンテキストが決定されると、ソフトウェアの価値基準の戦略的な見直しが発生しなければ境界づけられたコンテキストそのものの変更が発生しないことが多いようです。

まとめ

ここまで読んでいただきありがとうございました。
ソフトウェア開発の原料は言葉である。』という名言があります。
ドメイン駆動設計の戦略的分析で重要となる要素は、『ユビキタス言語』と『境界づけられたコンテキスト』の二点の構築が必要であると述べました。これらはソフトウェア開発の現場で生物のように有機的な変化や進化をしながら構築されていく物です。このトピックを読んでくれた方が、より具体的で実践的なユビキタス言語と境界付けられたコンテキストを構築する助けになったら幸いです。
 24日目は、@j5ik2o です。お楽しみに!

補足

実際にどのように『ユビキタス言語』と『境界づけられたコンテキスト』が構築されるのか拙筆スライドも併せてご覧ください。

エンジニアのためのドメイン駆動設計実践入門 / DDD for Engineer newbie


Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした