はじめに
前回のpart2で「境界づけられたコンテキスト」について紹介しました。
私はこの用語の意味を、システムを「チームやシステムごとに独立して意味を持つ領域に分割」することで、複雑さを管理しやすくする考え方と説明しました。この説明には概ね満足していますが、領域に分割という部分がうまくかみ砕けていないと思ったので今回このような記事を書くことにしました。
前回のコラムだと思って読んでいただけるとありがたいです。
解説
まずは公式の説明を読んでみましょう。
bounded context
A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.
（和訳）
境界コンテキスト
特定のモデルが定義され、適用される境界（通常はサブシステム、または特定のチームの作業）の記述。
引用元：DDD Reference
やはりいまいちよく分からないですね、、、
では、具体例を用いて考えてみることにしましょう。
今回はUber Eatsのような食事配達システムを想定します。このサービスに関わるのは以下のような人がいるでしょう。
- 1,開発部門
- プログラミングなどの開発を行う。
- 2,経理部門
- 金額面での管理を行う。
- 3,配達部門
- 料理を届ける。
ではここで、「料理」という言葉にこれら全ての概念（モデル）を持たせるとどうなるでしょうか？
エンジニアの立場になってみましょう。DDDではこの定義をコードに反映させなければなりません。さらに、ここに料理部門などが入ってもっと複雑になるとぐちゃぐちゃになってしまうのが想像できるでしょうか。
そこで大きなシステムを領域に分割するのです。この場合では、経理と配達の部門（領域）でそれぞれのモデルにしようということです。よって、「経理コンテキスト」と「配達コンテキスト」に分けてみよう、となるわけです。
おわりに
「境界づけられたコンテキスト」について理解を深められたでしょうか？具体例から気づいた方もいると思いますが、DDDは大規模システムの開発に有効な手段です。今回の学びを活かしてこれからも頑張りましょう！
では、最後まで読んでくださりありがとうございました。