アルプ株式会社でエンジニアをしています、集約のエンティティ@pictinyです。
この記事はドメイン駆動設計#1 Advent Calendar 2019 4日目のエントリです。
3日目は@dnskimo@githubさんのPofEAAで考える値オブジェクトの永続化あれこれでした。
ユビキタス言語
DDDを実践したとき、即座に真価を発揮するポイントが2つあると思います。
一つは、対象の問題領域をドメインを認識し、境界付けられたコンテキストを意識してドメインを理解しようとすること。もう一つは、ユビキタス言語を使い、ドメインに対して統一された命名をラベリングすることです。
ドメインモデリングを議論するためにユビキタス言語は不可欠です。共通言語を使う、というだけでユビキタス言語の目的の半分以上は達成できていると思いますが、しかしその命名について語られることは多くありません。
ひとたびユビキタス言語が定義され、会話やドキュメントに登場するようになると、徐々にチーム内に浸透していきます。最終的には関数名や変数名やテーブルの命名にも使われて、一度定着すると簡単には変更できないのがユビキタス言語です。なので、最初の命名で大きく外さないことは結構重要であるように思います。（もちろん、ドメインモデリングを進める中で、より適切な用語や表現にアップデートしていくことが大前提にあります）
アンチパターン
良い命名へと近付けるプラクティスとして、アンチパターンを避ける戦略が考えられます。
経験則ですが、以下の傾向が強い用語はなるべく避けるべきであると思います。
- 抽象的すぎる
- 汎用的すぎる
- 曖昧すぎる
具体例
今のプロジェクトではメンバー全員がユビキタス言語を意識し、一つずつチームで合意を取りながらユビキタス言語を育てています。その実践の中で、ユビキタス言語の命名に使わなかった単語、避けるべきだったかもしれない用語を、いくつかご紹介します。
モデル
抽象的すぎる例です。
モデルという言葉は抽象的すぎるので、「〇〇モデル」と命名しても「〇〇」と比べてさほど具体化されません。
設定
汎用的すぎる例です。
何かの振る舞いに影響を与える項目は全て設定と言えるかもしれません。
設定という単語を思い浮かべたならば、何に対する設定なのか、の方を言語化した方がよさそうです。
更新、変更
これも汎用的すぎる例です。
CRUDのU、Updateは全て更新、変更です。
何を更新するのか、あるいは何のために変更するのかを考えてみたいです。
有効
曖昧すぎる例です。
何が有効なのか、何に対して有効なのか、無効であるとすれば何を意味するか、などを考えて、曖昧さを排除できるとよさそうです。
おわりに
ユビキタス言語はその対象を可能な限り、具体的に、明確に、重複のないように命名できるとよいと思います。
言うは易し、行うは難し、なのですが。
ユビキタス言語の命名で後悔した経験や、アンチパターンだった用語はありませんか？
あったらこっそり教えてください。