DDDエンティティIDからのURLフレンドリーID
私は現在DDDを学習しており、WebアプリケーションにURLフレンドリーなIDを実装する方法について頭を悩ませています。
私の知る限りでは、DDDでは、自然な一意の識別子を持たないドメインエンティティの識別子としてUUIDを使用するのが一般的です。ドメインにはデータベースに関する知識がないため、これが唯一の一意の識別子になります。
通常、データベースにクエリを実行し、アイテムを取得して、 '/ item/{id}'のようなアイテムのURLを作成します。ここで、{id}はデータベースIDなので、 '/ item/12345'のようになります。
現在DDDで私を困らせているのは、ドメインエンティティのリポジトリにクエリを実行すると、一意の識別子としてuuidを持つドメインエンティティが得られるという事実です。このため、アイテムに対して生成するURLは '/ item/4020fd9e-8655-4c2b-93d0-c283210753d9'のようになります。これはばかげて見え、長すぎます。
私はこれを考えすぎていますか？
これに対処する方法は何でしょうか？
DDDはあなたのビジネスについてです。わかりやすいURLはビジネスドメインの一部ですか？
答えが「はい」の場合は、フレンドリーなURLを表す属性をエンティティに追加します。場合によっては、わかりやすいURL（またはslug）を生成するためのルールが複雑になることがあります。正直なところ、SEOの目的以外に、わかりやすいURLの利点はわかりません。フレンドリURLの要件は、主に技術者からのものであり、ドメインの専門家からのものではありません。
このため、アイテムに対して生成するURLは '/ item/4020fd9e-8655-4c2b-93d0-c283210753d9'のようになります。これはばかげて見え、長すぎます。
ばかげて見える
ここにAPIを記述していると仮定すると、誰もURLを見ることはありません
長すぎる
URLの最大長はブラウザによって異なりますが、ここでは2000文字について話します。 URLが長すぎません。
UUID/GUIDの主な利点は、どのコンピューターでも、既に使用されているかどうかを確認する必要なく、それを生成できることです。
実際には、これは、APIのクライアントがIDを使用して新しい項目を作成し、それを操作し、他のものに結合することなどができることを意味し、準備ができたら、POST IDがすでに使用されていることを心配することなく保存されます。