DDDについて学習中です。
DDDにおいて、業務エキスパートとソフトウェア技術者の間にある知識のギャップを埋めることが効果的と書かれておりました。
実務で生かすためにも、実際にこのギャップを埋めるために実施して良かったことを伺いたいです。
実際にコミュニケーションミスが減ったり、開発しやすくなる等、目に見えた何か具体的な効果はあるのでしょうか?
「同じ言葉」は、解決したい課題からコードに落とし込むまでのコミュニケーションのミスを減らすことが目的と認識してます。
書籍の内容だと、実務レベルで具体的にどのようなアクションをすれば良いかイメージが湧きませんでした。経験ある方がいれば教えてほしいです。
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
回答7件
#1
総合スコア4400
投稿2025/11/18 05:10
こんにちは。
「同じ言葉」というのは、要するに、現場 (ドメイン) で利用されている言葉と、システム内のロジックで利用されている言葉の2つを合わせるということです。
すなわち、この概念を実装レイヤに落とし込む場合、これは「名前付けのためのプラクティス」だと考えると良いです。
システムのロジックについて口頭で話したとき、それが現場の人間に通じることと、現場の人間の要望を口頭で聞いた時、それをシステムのロジックとして考えられることで、システムについての認識が合うため、成果物の品質が大幅に向上します。
すなわち、現場の人間が〇〇と発言したとき、それはシステム上でいう□□+△△のことだなと翻訳が必要になっているとどこかで要件の把握ミスなどにつながるので、〇〇だと一発で分かる (同じ) 名前を付けましょう、ということです。
最初の一歩としては、システム内の概念に名前を付けるとき、まずそれらが「現場 (ドメイン) では何と呼ばれているか?」を調べて認識合わせすることから始めると良いでしょう。
#2
tamotoさんありがとうございます!
最初の一歩としては、システム内の概念に名前を付けるとき、まずそれらが「現場 (ドメイン) では何と呼ばれているか?」を調べて認識合わせすることから始めると良いでしょう。
なるほどです。ありがとうございます!
ただ、厳密にすると名前を改修などあった場合、混在しそうですね。。
tamotoさんも実際に、現場とシステム内のロジックで利用されている言葉を同じにした結果、成果物の品質が向上されたご経験はあったのでしょうか?変更した結果良かったことなどお伺いしたいです。
また、他の現場でも同じ言葉にする動きは一般的なのでしょうか?mm
#3
総合スコア4400
投稿2025/11/27 00:18
#2
返答が遅れまして申し訳ありません。
(ドメイン側の) 名前を改修するというシナリオがあまり思い浮かばないのですが、ドメインで名前を変える必要性が発生したなら、システム側も名前を変えるという改修を入れるのが当たり前といえます。
DDD は常にドメインを主として設計を行う思想なので、ドメインに何らかの変更があったのにシステムに変更が行われないのは、「誤った流用」(間違っているけど、動いているからこのままで) となっている可能性が考えられます。
名前が厳密に一致している必要はなく、「お互いにその単語で何を指しているかが伝わる」状態を維持することが重要です。
言葉を同じにしたことで品質向上を実感したかと言われると、自分で触った範囲では実感したことはあまりないですが、他人の作ったシステムの名前の意味が分からなくて苦労した経験はあります。
自分で名前を付けると自分が理解できるのは当たり前なのですが、それがチームの全員やドメインの作業者全員に同じように伝わることが求められるので、名前についても相互に客観的なレビューを行うように、開発体制から改革が必要だったりします。
名前付けについて、雑な例で見せますが、
例えば「調理場」のドメインに関するシステムを作るとき、
現場で言う「オーブン」をシステム内で「加熱機能」とはせず「オーブン」とした方が良いし、
現場で言う「冷蔵庫」をシステム内で「材料倉庫」とはせず「冷蔵庫」と名前を付けたほうが良いと思いませんでしょうか。
どんな現場でも、協力関係にある現場同士には規模の大小こそあれ必ず「共通言語」の概念が存在するので、それをシステム開発に取り入れるプラクティスに名前を付けたものを「同じ言葉」と呼んでいると理解すれば良いと思います。
#4
総合スコア2088
投稿2025/11/30 12:15
「業務エキスパートとソフトウェア技術者の間にある知識のギャップを埋める」について聞きたいのか、「同じ言葉」について聞きたいのかよくわかりませんでした。
とりあえず後者と仮定するなら、やることって実質「用語集作りましょう」「関係者で読み合わせして違和感があるところはどんどん修正していましょう」でしかないです。
ECサイト利用者が行うのは「注文」なのか「発注」なのか「購入」なのか、ECサイト管理者が管理するのは「注文」「受注」どっちなのか、BCtoBtoB なら 卸やメーカーへの「注文」や「発注」がありますが、この「注文」「発注」とECサイト利用者の「注文」「発注」が紛らわしくないのかとか、などなど。
#5
他人の作ったシステムの名前の意味が分からなくて苦労した経験はあります。
ご回答ありがとうございます。
そのような経験があったんですね。やはり後から読みづらさや改修を考えると初期設計の段階で検討するのが大事であることを知りました。
#6
とりあえず後者と仮定するなら、やることって実質「用語集作りましょう」「関係者で読み合わせして違和感があるところはどんどん修正していましょう」でしかないです。
ご回答ありがとうございます!確かに用語集あると開発時も共通認識取れそうですね
#7
総合スコア6431
投稿2025/12/10 01:05
会話をして認識の齟齬を無くせというのが答えですが、きっとそれじゃ腑に落ちないですよね?
あなたの職場で作っているサービスについて、プログラマーと非プログラマーのどちらもが無関係の第三者に対して同じ理解をさせられるような説明ができる状態になった時が、あなたの読んだ本に書かれているらしい「同じ言葉」で話せるという状態でしょう。
その状態を目指す為には何をしたら良いかを考えてみてください。会話以外でも色々出てくると思います。それが答えです。
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。