【DDD実践思考メモシリーズ】ツーサイドマッチングプラットフォームにおけるユーザードメインの扱い方について

#　ツーサイドマッチングプラットフォームとはなにか？
あまり聞き馴染みのない言葉かもしれないですが、
例えば複業クラウドは企業と働き手をマッチングさせるためのプラットフォームなので、
性質の異なるユーザーが二種類存在し、両者をマッチングさせるサービスです。

複業クラウドのマッチング図

企業は求人を出して求人を通してタレントと企業がマッチングする仕組みとなっている

ツーサイドマッチングプラットフォームにおけるドメイン設計の難しさとは？

上記の図からDomainモデルとしては

• Company
• JobOffer
• Talent

などが作成されると思います。
ただしこれはCompany、 Talentのどちらもユーザー側の目線として作られたものになります。
複業クラウドは求人に対してエントリーすることもできるし、企業側からタレントに対してスカウトを送ることもできるので、
企業から見た時にはタレントがコンテンツであり、タレントから見た時は企業はコンテンツであるということが考えられます。

企業がタレントを見る際にはメールアドレスなどの個人情報を見ることはできないですが、タレントがユーザーとして活動する上ではメールアドレスは必要になります。
ここでコンテンツとしてのモデルと、ユーザーとしてのモデルは乖離が生まれます。

タレントというコンテキストと企業というコンテキストで完全に分けてしまうのはだめなのか？

ここもかなり難しいところで実際に分けているチームもあるとは思いますが、あくまでマッチングプラットフォームであり、かつメッセージなどのやりとりが発生し、両者のユーザーの直接的な接点が多いサービスなので完全に分断してしまうのは良くないと考えています。

例えば

• 求人
• スカウト
• エントリー
  は両者ユーザーをつなぐものであるのでここのコンテキストが二重管理のような状態になってしまう危険性があります。

適切なコンテキストでドメインを分解する

そこで弊社ではドメインレイヤーにタレント検索というモジュールを作成し、Talentエンティティーと検索で利用されるコンテンツとしてのTalentエンティティーを作成しました。

- domain
 |- talent
   |- talent.ts
 |- talentSearch
   |- talentSearchItem.ts

Another worksでは一緒に働ける仲間を募集しています！

またもし気軽に話だけでも聞いてみたいという方がいれば私やPMの宮内とお話しできればと思います！