ドメインモデリングのようなことをしたログ

最近何回か試してみたらとても良かったので、やったことと良かったポイントを書きたいと思います。

どんなことをしたか、実際やってみてどんな効果があったかという話がメインになりますので、ドメインモデリングをちゃんと学びたい場合は他の記事をご覧いただくのが良いと思います。

おことわり

• ワンショットで試しただけで、継続して活用しているわけではないです
• 実際はER図を囲んで話したくらいのもので、ドメインモデリングというほど大層なことはしてないです

何をしたか

• ER図もどきに毛が生えた程度の図を元に対話を行いました
• （実際取り組んだのは別のドメインですが、）フリマサイトの想定でお話しします
  • 記事用に図を作成しているので、実際使ったものより簡素になってます
• チーム規模としては2名のビジネスメンバーと2名のエンジニアという構成を想像していただければ

モデルの経緯

初手はヒアリングした内容を元にこのような構成で開発を行っていました。その後様々な要件が出てくるに伴い、開発側で改善を重ねていきました。

二段階目

• ユーザーは購入者としても出品者としても利用するケースが多い
• 購入時と出品時でプロフィールを出し分けたい

ということで、育ったものがこちら。

このあたりから、「購入者アカウント」というワードが登場したり、上記に含まれていない部分でもコード上に表現していないワードで話が進むなど、ユビキタス言語の不在に起因する認識の齟齬（があるかも感）が出てきました。そのため整理したいなーと考え始めました。

対話での活用

まずは現状の実装とドメインが一致しているかを全員で確認してみました。

• アカウントと呼べるものはユーザーのみである
• 各ロールは主にプロフィール置き場の役割を持ち、ロール特有の関連データが紐づく

次に、新たに出てきた機能案を軸に改めてユーザー周辺のモデルを整理しました。

• 基本的には個人同士が活動する場だが、企業に所属する出品者として活動するケースもある
• また、複数企業に所属することも許容する

これを前述のモデルをベースに、ライブで編集していきました。
単純に考えるとこう。ユーザーが出品ロールを複数保持できるようにすればOK。

図を調整した結果、リアルタイムで出てきた論点は以下のようなものでした。

• 「同時に複数企業で活動することはありえるだろうか」
• 「企業内で、購入者との事務的なやりとり・手続きだけを担当するロールも必要かもしれない」
• 「出品ロールが不要になり削除する際に、メッセージの引き継ぎができるようにしたい」

ここでこの取り組みの価値を強く感じました。ここまでは開発者がアイデアを受け取ってディスカッションをリードしてようやく出していたものが、自然とチームから出てきた上に精度もスピードも断然上でした。各々が専門性をもとにモデルを発展させることはとても有益ですね。
この後も商品や取引に関するモデルまで話題が発散し、チーム全員でドメインの理解を深める時間となりました。

まとめ

最初から会話のお供に作成しておけばよかったなあと思いました。
これくらいの内容でも試してみると大きな収穫があると気づけたのは良い経験でした。