DDDの初心者がDDD設計を基に開発を行うチームで気づいたユビキタス言語とドメインのこと

はじめに

こんにちは。カケハシの患者リスト開発チームの金と申します。 患者リストはWEB業務アプリとして、薬局から患者さんへのフォローで関係性を向上させるためのツールです！

患者リスト開発チームではDDDとClean Architectureを基にしてスクラム開発を行なっています。 私はこのチームに入って半年で、患者リスト開発チームに入る前まではDDDとClean Architectureに関してあまり知識がない人でした。 この半年DDDに関して学んだり気づいたことが多いですが、その中で、ユビキタス言語とドメインについて少々考えたことを記述してみたいと思います。 DDD初心者目線の記事になります！

DDDを知らない方のために「ユビキタス言語」と「ドメイン」の定義を記載しておきます。 DDDに詳しくなく、定義だけ知っている程度でも問題なく読んでいただける内容となっています！

ユビキタス言語: チームの全員が特定の用語を聞いたとき、同じことを考えるように定義された言語

ドメイン: 現実の解決したい問題領域

ユビキタス言語を上手く使うチームはコミュニケーションと開発のスピードが速い

最初ユビキタス言語の印象

私はチームに入ったばかりの時、ユビキタス言語が上手く決められていることの何が良いかあまりわからなかったため、 ユビキタス言語を決める「Aという新しいもの」をどう呼びましょうか？みたいな会話に時間をかけることに疑問を持っていました。 そのため、ユビキタス言語をそこまで意識しなかった気もします。

その考えはすぐ問題に

ただ、これはコミュニケーションにおいて問題を発生させる原因になりました。 他のメンバーが同じ案件について議論をしている時に、私は用語の意味について考えたり、 用語を聞いた時に浮かぶいくつかの案件からどの件に関する議論か考えながら特定する時間が必要だったため、無駄な時間が発生しました。 例えば、「処方箋A」は特定の条件を満たす処方箋を指し示すチーム内用語だったのですが、 私は本来の「処方箋」の意味から類推しようとした結果、正確な意味を理解することができず無駄な時間が発生したことがありました。

必要性と良さに気づいた

ユビキタス言語の定義は「チームの全員が特定の用語を聞いたとき、同じことを考えるように定義された言語」になると思います。 「チームの全員が特定の用語を聞いたとき、同じことを考える」言葉だけではそこまでインパクトがある言葉には感じられないかもですが、 これはすごいことだと思います。 前提を持って理解することは、前提の全くない白紙の状態から理解するのと比べて、明らかに理解が早いと思います。

コードでも力を発揮するユビキタス言語

ユビキタス言語はコミュニケーションの時のみではなく、コードを書く時もかなり力を発揮すると思います。 関数、クラス、変数の名前を見た瞬間に「あ、これはOO案件と関連がある部分でOOを表現している」とコンテキストを把握することができるため、 理解をする時間とコードを追う時間が大幅に短縮できると思います。

患者リストチームでのユビキタス言語

患者リスト開発チームではユビキタス言語をかなり大事にしていて、 単なる辞書のような整理をするのでなく、絵やFlow図で用語を直観的に理解できるようにしています。 あとチーム全員の納得の上、わかりやすい単語にユビキタス言語を選定するなど努力をしています。 コードにそのユビキタス言語を落とすことももちろん意識して行なっています。 これらを普段意識して行うことで、実際リファインメントやスタンドアップの時間にスムーズな会話ができていると思います。

DDDのコアドメインは難しく複雑なものではない、単に「現実の解決したい問題領域」だった

ドメインの話をするときは技術の話をする必要はないことに気づいた

私がある日、突然ドメインについて理解できるようになったのはチームのリファインメントの途中だったと思います。 ふと、「以前DDDを使ってなかったチームでは企画の方と話すことが大変だったけど、患者リストチームではPdMとの会話がものすごくスムーズだな。 なぜだろう」 と疑問が湧きました。答えは単純な理由でして、会話をする際に「現実の問題をどう定義してどう解決および表現するか」だけを語り、 技術の話（例えば、DBのフラグが〜〜だから〜〜にしないと）はほとんどないからでした。 そうでした、ドメインは本当に「現実の解決したい問題領域」で、それを理解するための概念モデルがドメインモデルでした。

Domain ModelとDB Modelは1:1ではない、同じものではなかった

ドメインモデルとデータベースモデルは同じものではない。 私にとってはこの点が少し理解しづらいポイントでした。 チームに入るまでに設計と開発をDBから行なっていたためか、 当初は患者リストチームで設計をする時に「ドメインをDBにどうやってあわせるか」だけを、 言い直すと「DBにどうやってドメインを合わせるか」だけを考えていました。 つまり、私はドメインモデルとDBモデルを別で考えるのではなく、ほぼ同じもので扱ってドメインよりDBをコアに思っていたかも知りません。

ドメインモデルはドメインを理解するための概念モデルで、DBモデルはドメインを技術的に実現するための、実現モデルと言えるものです。 そのため、必ず1:1になるものでもないし、同じものでもない。DBモデルはコアではないです。

最後に

DDDは敷居が高く感じられる面もありますが、知れば知るほど面白い開発手法だと個人的に思っております。 その分奥が深いとも思います。 上手く活用すると開発コスト削減と楽しい開発につながると確信しております。 今回は初心者の目線でDDDのユビキタス言語とドメインについて軽く触れましたが、 次回にDDDをTopicにして記事を書くときは詳しく触れたいと思います。