ドメインとコンテキストの関係とチームの単位
ドメインと境界づけられたコンテキストとチームの単位について最近考えることが多いので、整理のためブログに残しておきたい。もちろんここに書かれた内容はいろいろな書籍から自分なりに噛み砕いた解釈なので、異なっている部分もあると思う。
ドメインとは
システムが対象とする現実世界の概念のこと。
境界づけられたコンテキストとは
ドメインが特定の意味を持つための条件のこと。
よく挙げられる例として「商品」というドメインは消費者から見た場合と、在庫を管理するスタッフから見た場合とでは、意味合いが変わってくる。後者の場合では「商品」というより「在庫」と呼ばれるだろう。この場合では「商品」というドメインに対して「購入」というコンテキストと「在庫管理」というコンテキストが考えられそうだ。
あるドメインを表す言葉(ユビキタス言語)はコンテキストの中では一意の意味を持つことになる。
ドメインとコンテキストの関係性
ドメインとコンテキストの関係性について、フリマサービスを例に考えてみたい。フリマサービスに関わったことがないので、ドメインの理解としてそもそも間違っている可能性があるけどそこは目をつむってほしい。
このフリマサービスは以下のような機能を持っているとする。
- ユーザーは自由に商品を出品できるし、また出品された商品を購入することもできる。
- サービスの運営者は不当な取引がないか商品を検閲している。
「ユーザー」「商品」「出品」「購入」「検閲」などのドメインらしき概念が出てきた。
まずは、どんなサービスにも存在する「ユーザー」という概念から整理してみる。ユーザーは購入するときには購入者と呼ばれるし、出品するときには出品者と呼ばれる。これはつまり、「購入」のコンテキストと「出品」のコンテキストがあるということを意味している。
次に「商品」について考えてみる。「購入」のコンテキストでも「出品」のコンテキストでも商品は商品であろうと思えそうだが、よく考えるとこれも区別する必要があることがわかる。例えば、「出品」のコンテキストでは「商品」には非公開・公開といった表示ステータスや、未購入・購入済みといった購入ステータスが考えられるが、「購入」のコンテキストでは非公開の商品や購入済みの商品は存在する必要がないため、考慮する必要がない。さらに、運営者が検閲する際に「商品」の掲載可否を表すステータスや、掲載できなかった場合の理由といった情報が加わるだろう。つまり、ここには「検閲」というコンテキストが存在することになる。このように「商品」というドメインはコンテキストにより微妙に関心事が異なっており、意味合いが異なると言える。
ここまでを表にまとめる。
ドメイン\コンテキスト | 購入 | 出品 | 検閲 |
---|---|---|---|
ユーザー | 購入者 | 出品者 | 運営者 |
商品 | 商品 | 商品 | 商品 |
「ユーザー」というドメインはコンテキストによって呼び方が変わることがわかった一方で、「商品」というドメインはコンテキストが変わっても特に呼び方が変わるわけではなかった。それでも、コンテキストにより意味合いが異なることがわかった。場合によって呼び方が変わる概念にはコンテキストが潜んでいることが分かりやすいが、現実世界ではまれであるようにも思える。それでも、場合によって関心事が変わるということは必ずあるはずで、それを見逃さずにコンテキストとして整理できるとよいだろう。
チームの単位
システムが成熟し巨大化してくると、扱うドメインもコンテキストも当然増えてくる。開発チームの全員がそれらすべてを理解するのは徐々に認知負荷が高まりデリバリーの遅れや品質の悪化につながるため、どこかでチームを分割し、担当領域を割り振る必要が出てくる。そこで、どのように分割すると効果的なのか考えたい。
ここで、フリマサービスが成長し機能が増えた結果、ドメインやコンテキストが以下のような表に整理できたとしよう。
ドメイン\コンテキスト | 購入 | 出品 | 検閲 | 広告 | ... |
---|---|---|---|---|---|
ユーザー | 購入者 | 出品者 | 運営者 | ||
商品 | 商品 | 商品 | 商品 | ||
A | |||||
B | |||||
C | |||||
... |
分割の仕方としては2つ考えられる。
- ドメイン単位で分割する。「ユーザー」チーム、「商品」チームといった具合に分割し、そのドメインが関わるコンテキストをすべて扱う。表で言うと、行ごとにチームを割り当てることになる。
- コンテキスト単位で分割する。「購入」チーム、「出品」チームといった具合に分割し、そのコンテキストが関わるドメインをすべて扱う。表で言うと、列ごとにチームを割り当てることになる。
どちらにしてもチームの数には限りがあるので、近接するいくつかのドメイン/コンテキストをチームに割り当てることになるだろう。
2つの分割方法のうち、コンテキストの単位で分割する方がいいと思う。理由としては、1つのコンテキストに複数のチームを割り当てると、同じコンテキストの中でチームごとに固有のユビキタス言語が生まれやすくなってしまうからだ。1つのコンテキストには一意に意味が定まるべきなので、ドメイン単位で分割するのは得策とは言えない。
DDDの書籍を読むとわかることだけど、各チームはコンテキストを所有し、ユビキタス言語に沿った独自のドメインモデルを構築し、コンテキストマッピングに従って他のコンテキストとのコミュニケーション手段を実装していくことになる。