はじめに
初めまして!株式会社GROWTH VERSEでEpic Owner兼バックエンドエンジニアとして働いている川田です。2023年11月にGROWTH VERSEに転職し、現在まで約半年が経過しました。私がGROWTH VERSEに入社して少し働いてから、以下のようなことを考えていました。
AIMSTARって機能豊富で機能自体も複雑だな!!
それなのにAIMSTARで登場する概念や機能・登場するモデル、モデル間の関係性に関してまとめられたドキュメントが全然ない!!
プロダクトが扱うドメインが難しいため、新しく入った人がドメイン知識得るまでにどうしてもオンボーディング時間がかかってしまう…
弊社以外でも、上記のような課題を持っている開発チームは珍しくないかなと思います。ドメインモデル図を作成し、ユビキタス言語を定義することは上記のような課題を解決するための有力な手段となります。これらを導入することで、以下のような成果を期待できます。
- 開発チーム全体のドメイン知識の理解向上
- ソフトウェアの保守性向上
本記事では、ドメインモデル図やユビキタス言語とは何か、ドメインモデル図やユビキタス言語を作成する目的などについてまとめようと思います。
DDDとは
DDD(ドメイン駆動設計)とは、ソフトウェアの設計手法の1つであり、Eric Evansさんが考案したものです。ドメインとは、システムが対象とするビジネスや業務領域を指します。DDDを実践することで、複雑なドメインを理解し、その知識をソフトウェア設計に反映させ、業務要件を満たす高品質なソフトウェアをシステマティックに創造することが目指されます。
DDDの実践例として、ドメインモデル図、ユビキタス言語、レポジトリ、集約、エンティティ、値オブジェクト、ドメインサービスなど多くの概念があります。本記事では、ドメインモデル図の作成とユビキタス言語の定義に焦点を当てようと思います。
ドメインモデル図とは
ドメインモデル図とは、ソフトウェア開発プロジェクトにおけるドメインの概念的な表現です。このモデルは、ドメイン内の主要なエンティティ、それらの属性、エンティティ間の関連性および制約を視覚的に表現します。ドメインモデル図は、ドメイン駆動設計の中心的な要素であり、開発者とビジネス専門家が共通の理解を持つための重要なツールとして機能します。
ドメインモデル図の例は以下のようなものです。
こちらは給料管理システムのドメインモデル図を想定しています。上記のような図があるとモデルの属性やモデル間の関係性を視覚的に理解することができます。
ドメインモデル図があるとどう変わるか
ドメインモデル図があると、以下のような効果を期待できます。
- 新規参入者がプロダクトに登場するモデルやモデル間の関係性をより早く理解し、より早い即戦力化を期待できる
- モデルが及ぼす影響範囲をより早く理解するための手助けとなり、必要に応じてドメインモデリングの変更を第三者が容易にできる。
- 第三者に対してソフトウェア上でドメインをどのように表現したか説明可能。フィードバックを得やすい。
ドメインモデル図の書き方
ドメインモデル図は以下のような流れで作成しています。
- 求められるビジネス要件を理解
- ビジネス要件を満たす上で必要なモデルを定義
- モデルの属性を定義
- 関連性の定義
- 集約の定義
集約に関しては、ドメインモデル図の中で定義しなかったとしても、データの関係性の強度を整理するために意識する必要があります。私はライフサイクルが同じモデルに関しては共通の集約に配置し、異なるモデルは別の集約に配置するように意識しています。
ドメインモデル図の作成は複数人でやりたい
ドメインモデル図の作成はエンジニアが一人で行うのではなく、複数のエンジニア、理想を言えばPdMも交えて行うのが理想です。
複数のエンジニアが共同でドメインモデリングを行うメリットとして、以下のようなものが挙げられます。
- 技術力、設計能力の向上
- 開発チーム全体のソフトウェアに対する理解の促進
- 設計、開発時のレビュー対応の高速化。設計レベルの修正によるコードの修正を防ぐこと可能
また、PdMと共同でドメインモデリングを行うメリットとして、以下のようなものが挙げられます。
- 開発チームがビジネスの視点からよりドメインに対して知識が深まる。
- 開発チームが技術的な視点だけでなく、ビジネスの視点からも設計を理解し、両者のギャップを埋めることができる。これにより、ビジネスの目標と技術的実現可能性が同時に考慮されるため、最終的なプロダクトが市場の要求にぴったりと合うことを期待できる。
複数人でドメインモデリングを行うことは、技術面、ビジネス面で大きなメリットがあります。勿論、複数人で対応することで一時的にベロシティが下がるというデメリットがありますが、それ以上に複数のエンジニア、PdMを交えてドメインモデリングをすることは、長期的に非常に良い取り組みだと思います。
ユビキタス言語とは
ユビキタス言語は、ドメイン駆動設計の中核的な概念の一つで、プロダクトのすべての関係者が共通で使用する言語です。この言語は、開発者、ビジネスアナリスト、プロダクトマネージャー、その他のステークホルダーが同じ用語を使ってコミュニケーションを取ることを目的としています。
ユビキタス言語の例は以下のようなものです。サービスはECプラットフォームを想定しています。
- 商品:商品という用語は、販売される個々のアイテムを指す。これには名称、価格、説明、在庫状況などの属性が含まれる。
- 顧客:顧客はサービスを利用するユーザーで、名前、住所、メールアドレス、注文履歴などの情報を持っている。
- 支払い:支払いは顧客が商品の代金を支払う行為やプロセスを指す。支払い方法(クレジットカード、PayPal、代引きなど)や支払い状態(未払い、支払い済み、払い戻し)を含む。
- 配送:配送は商品が顧客に届けられるプロセスである。配送方法(宅配便、郵送、即日配送など)、配送状態(準備中、出荷済み、配送済み)、配送先住所などの詳細が含まれる。
ユビキタス言語を定義する目的
ユビキタス言語があると以下のような効果を期待できます。
- 新規参画者がプロジェクトに参加した際、ドメイン知識をより早く身につけることが期待できる。
- 言葉の意味に関する齟齬を減少させ、コミュニケーションの効率と精度を向上させることができる。異なる背景を持つチームメンバー間で用語が一致していないと、誤解が生じやすくなる。
今後の展望
現在、弊社ではドメインモデル図の作成やユビキタス言語の定義の推進を進めており、新規で参画するエンジニアの早期の即戦力化、エンジニアのドメイン知識の強化などが期待できる環境を目指しています。
まとめ
DDDの概念を全て設計に取り入れたら良いという訳ではないですが、複雑なドメインに向き合うために必要に応じてDDDを部分的に取り入れることは良い取り組みだと思います。弊社と似たような悩みを抱えている開発チームの一助となれば幸いです。最後まで読んでいただきありがとうございました!
また、DDDの導入のような新しいチャレンジが好きなエンジニアを、積極採用中です!