目的
ドメイン駆動設計の本を読んでいると、たびたび出てくるBounded Contextですが、
(日本語だと、境界付けられたコンテキストと表現されます) 以下の情報は文献を読めば書いてあります。
- Bounded Contextをシステム境界にするとよいだろう
- この具体例だとここがBounded Contextと言えるだろう
しかし、実際に自分たちが扱っているドメインのBounded Contextを定義したい場合にその方法を書いてある文献はありません。
この記事を通して、みなさまのドメインのBounded Contextを定義する手助けをできればなと思います。
Bounded Contextとは
Evans本で久々にBounded Contextの章を読み直しましたが、いい感じにまとまっている箇所があったので引用します。
Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don't be distracted or confused by issues outside.
一言で表現するのは難しいですが、Bounded Contextはユビキタス言語の境界であり、ドメインの境界であります。
そもそもBounded Contextを定義することの何が嬉しいの？
戦略的設計を行う際に、Bounded Contextに沿ってモジュール/サービスを分けることができたら、
高凝集・疎結合なまとまりになりやすいと言われています。
Sam NewmanさんのBuilding Microservicesを読んだ方ならピンときたかもしれませんが、
マイクロサービスの境界の指針にもなります。
マイクロサービスと行かないまでも、サービスの境界を定義するときは高凝集・疎結合な単位でシステムを分割することができればお互いの依存が少ない形でシステムが構築できます。
モノリスをサービスに分割したい、というときや新しいドメインでシステムを作りたいというときにBounded Contextを定義できれば、それに沿ってサービスを作るように設計することで高凝集・疎結合なサービスへの順調な第一歩が踏み出せます。
Bounded Contextを定義するヒント
さあ、Bounded Contextを定義するメリットは分かりました。
「結局どう定義すればいいの？」に対する具体的な回答は最後に書くとして、その際のヒントを以下に書きます。
- Business Capabilityに着目する
- ユビキタス言語の境界に着目する
- アクターに着目する
Business Capabilityに着目する
Business Capability はそのビジネスが何をできるかを指す言葉です。
(日本語だとニュアンスが伝わりにくいので、英語文献でBusiness Capabilityについて記載がある記事をいくつか読めば感覚つかめると思います)
大きなドメインを小さいサブドメインに分けたいときにそのビジネスが何をできるかに着目して分けていけば、Bounded Contextを引くヒントになります。
ユビキタス言語の境界に着目する
例えば、同じ言葉で異なる意味を持つ言葉がある場合はBounded Contextを定義するヒントになります。
よく例に上がるのは"Account"という言葉です。扱うドメインの中で異なる意味で同じ言葉が使われている場合はユビキタス言語の境界があるということになります。
アクターに着目する
アクターもBounded Contextを定義する際のヒントになります。
例えば、会社の組織構造に着目すると「ほげほげ部」「ぴよぴよ部」等の部はヒントになります。
言われてみれば「ほげほげ部」の中で使われる「社内用語」ならぬ「部内用語」があるはずです。これはドメイン駆動設計では「ユビキタス言語」と言います。
Bounded Contextの定義方法
いろいろ書いてきましたが、Bounded Contextを定義するにはずばり、
正しい人を呼んで、全員で決める
拍子抜けしたかもしれませんが、自分の現在の結論はこれしかないです。
正しい人というのはドメインエキスパートを含む、チームメンバーです。全員で議論して決めるものだと思います。
同じドメインでも「何が実現したいか」によってBounded Contextは変化してくると思います。
なので、一意に決まるようなものではなく、言ってしまえば正解もありません。
自分の記事で「見つける」という表現を敢えてしていないのはそういう意図です。
「見つける」ものではなく、「決める」ものだと思っているからです。
チームでの決め方
議論を促進するように工夫をしてあげるのが大事だと思います。
- 会議ではなく、ワークショップにする。
- 大人数で集まっているなら半分ずつに分割して意見を吸いだす
などは実際に試してみて効果的でした。
また、Domain Driven Design Distilledの本の中でも紹介されているEventStormingという手法はワークショップの形式になっており、
チーム内の議論を活性化させるのに非常にいい手法なので、おすすめです。
おまけ
自分は最初、Bounded Contextを「見つける」ものだと思い、悶々としていました。
上で書いたように「もしかして、定義するものではないか」と解釈するようになってから、だいぶ気持ちも楽になったのと、
より主体的になれました。
具体的な定義方法は今の私から提示できませんが、この記事がだれかのヒントになれば幸いです。