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

ユビキタス言語についての知見を共有します

この記事は、ドメイン駆動設計 #1 Advent Calendar 2018の10日目です。

ユビキタス言語は大事

DDDは分類手法の一つという側面があります。

分類の道具は境界づけられたコンテキストと、ユビキタス言語です。
境界づけられたコンテキストで、システムの対象業務を分類し、境界づけられたコンテキスト内部ではユビキタス言語で言葉を分類します。

個人的に、ユビキタス言語はDDDを実践する上でとても大事なテクニックだと思うのですが、何を指すものなのか、どういうメリットがあるものなのかわかりにくいために、初心者にとってはわかりにくいものかもなー、とも感じます。
そこでこの記事では、ユビキタス言語についての私の知見を書いてみます。ユビキタス言語についての学習の助けになれば幸いです。

ユビキタス言語とは何か?

ユビキタス言語の定義をする前に、「境界づけられたコンテキスト」について説明します。

境界づけられたコンテキストとは「共通の用語が通じる業務の範囲」のことです。
DDDは全体で同じ用語を使うことは無理と考えますが、ある範囲であれば共通の用語を使えると考えます。その範囲が境界づけられたコンテキストです。

境界づけられたコンテキストは名前空間として働きます。ユビキタス言語とはコンテキストの内部だけで有効な用語集です。コンテキストを越えると同じ名前の用語であってもユビキタス言語としては通じず、別の概念になります。

例えば発送処理と請求処理でコンテキストを分けているとして、それぞれのコンテキストで「顧客」というユビキタス言語で定義された用語を使っていても、それらの用語は別の概念だとみなさないといけません。

ユビキタス言語はどのような用語集になるでしょうか?例えば発送処理のユビキタス言語は「発送」「発送者」「郵送先」「日付指定」「配達業者」「運転手」のような言葉を使うかもしれません。
大事なことは、ドメインのユーザーが使う言葉とプログラムを構成する言葉を一致させることです。プログラムの中で使われているクラス名、メソッド名をユーザーが見れば意味が通じないといけませんし、ユーザーが使っている言葉がついたクラスは、実際の言葉が指し示すものと同じように振る舞わなければいけません。

ユーザーが使っている言葉でプログラムを検索すれば、該当する概念の挙動を表しているクラスに行き着くようになってないといけませんし、そうなっている状態が保守しやすいプログラムであると言えます。ユーザーの言葉からプログラムの言葉に翻訳しないといけなかったり、一つの概念が複数のファイルに分割されている状況は可能な限り避けないといけません。

なぜ技術用語でなくドメインの言葉で分類するのか?

同じ言葉を使ってユーザー、ドメインエキスパート、開発者などの関係者が会話することで、ドメインを効率的に学習するため。
また、そうすることでうまく分類でき、理解しやすく保守しやすいシステムにすることを期待します。
保守しやすいプログラムにすることも目的です。

ドメインの言葉を使えば適切に名前付けできるのか?

この点は私がDDDを学び始めた時の疑問の一つでした。
適切に名前付けするとは、以下の条件を満たしていること、と言えるでしょう。

  • 名前でドメインの概念を識別できること
  • 理解しやすい名前付けができること

それぞれについて考えてみます。

ユーザーが使っている言葉を使って、適切に識別できる名前付けができるのか?

たぶんできる。
ユーザーは混乱の無いように業務を回しているというのがその根拠です。
曖昧な言葉を使っていたら、効率的に業務を行うことはできない。なので曖昧な用語は使わないように業務で使う言葉が洗練されている、と期待できます。

ユーザーが使っている言葉を使って、理解しやすい名前付けができるのか?

これもたぶんできる。けど、一見わかりにくい言葉を使っていることはありうる。
業務を回すには、曖昧な言葉を使うのはNGだが、関係者だけに通じる言葉が使われているかもしれません。
外部の目から見て不必要にわかりにくい言葉が使われているなら、それを理解しやすい言葉に置き換えてもいいかもしれないし、すでに共通言語として使われているメリットを活かすなら、そのまま使い続ける判断もあるでしょう。

ユビキタス言語を作る時の注意点

ユビキタス言語は、ユーザーが使っている用語を使うだけでなく、開発者も含めて共通に使う言葉を育てていくのだそうです。
ユーザーも業務で実際に使う必要があるため、以下の点に気をつけて言葉を選んでいかないといけないでしょう。

  • 同一コンテキストの中では、たとえモジュール(パッケージ)が別れていたとしても、同じ名前を異なる概念に対してつけてはいけない。パッケージ名を取り除いた名前だけで識別できないといけない。 普段の会話の中で、パッケージ名を付けて呼んだりはしないので。
  • 誤解を生じにくい言葉を選ばないといけない。そうしないとコミュニケーションが滞ってしまう。

「重複している」「曖昧である」と感じたなら、それは適切な名前付けができてないサインです。
そういうコミュニケーションのわだかまりを学習の機会と捉えて、言葉を整理して、ユビキタス言語を育てていかないといけません。

以上、ユビキタス言語の知見の共有でした。ご参考まで。

kmdsbng
京都で働いてるプログラマです
http://twitter.com/kmdsbng
mmj
ウェブシステム開発やサービスを運営している京都の会社です。Kotlin, TypeScript, Reactを中心とした開発体制への移行をしています。 その前はRuby on Rails を中心に開発をしていました。
https://www.mmj.ne.jp
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
ユーザーは見つかりませんでした