リボン図とBounded Context
世の中のいわゆるB to B to Cと呼ばれるタイプのWebサービスはリボン図で説明されるビジネスモデルがいまだ多い。
https://gyazo.com/691a1c7e753f6bc0aa0a17e0baa220ab
このときクライアントが提供する情報をカスタマとマッチングするので、多くのデータはクライアントとカスタマ共通であり、それゆえに事業設計においても同じ用語を使って業務シナリオが語られがちである。その結果、求人サイトならば求人票とカスタマアクションである応募エントリ、旅行サイトならば宿泊プランとカスタマアクションである予約、これらデータはクライアント/カスタマ共通のモデルで設計され、それを素直に実装すると共通のテーブルを参照するように作られる。
だが、事業が成長していく過程でクライアントとカスタマの機能で、ズレが生じていく場合がある。属性の違い、例えば応募エントリにはカスタマが登録するときには、氏名・性別が必須だが、クライアントには開示しない、などであれば、同一モデルで権限に応じて開示範囲を制御することが可能であり自然な設計に思える。だが例えば、ひとえに求人票といってもその指すもの単位がクライアントの都合だとポジションから求人票作るので、似た役割、スキル要求であっても異なる部署であれば2つ求人が作られるが、カスタマ側から見ると部署の違いは分からないので、同じ求人として取り扱った方がコンバージョンが高くなる、などが起こりうる。
そうした単一性や同一性、カテゴリのズレが生じるとクライアント/カスタマ共通で同じデータモデルを参照するのが事業成長の足かせになりかねない。また、カスタマ側のサービスは、同じクライアントからの情報を元にしても、異なる見せ方をするためやよりユーザを細かくセグメンテーションするために、複数の子ブランド展開していくこともある。これも共通モデルを使っていると、それがネックになるだろう。 したがって、大抵はBounded Contextをクライアントとカスタマで分けて作る方が良いのではという議論をするハメになる。であるのならば、スタートアップ時点で、そもそもこれ議論しておいて、共通モデルでスタートするにしても、どういう条件を満たしたらコンテキスト分割するというプランを持っておいた方がよいだろう。