3
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

ドメイン駆動設計入門#2 境界付けられたコンテキスト

Posted at

はじめに

本日はドメイン駆動設計の境界付けられたコンテキストについてまとめます。

本記事は以下の内容を備忘のため記載しています。
境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説
非常に参考になるので是非ご確認ください。

前回の記事はこちら

境界付けられたコンテキスト

ドメイン駆動設計の公式referenceでは境界付けられたコンテキストは以下のように定義されています。

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.	

日本語に訳すと、特定のモデルが定義される境界(ex.サブシステム、特定のチームの作業)を記述したもの。
特定のモデルが定義され、適用される境界の記述。 といった意味を示します。

前回の記事でも書いたように、
ドメイン駆動設計は、開発者一人で実践するものではなく、周りの人を巻き込み、すべての人(設計者、開発者、ドメイン駆動設計のエキスパート)が同じ意味でドメインモデルを理解し使えることが重要です。

参照した記事にあるれがわかりやすかったため、ECサイトの開発を例に以下を記述します。

ECサイトで商品を販売するシステムを例に考えます。その場合関係者はざっと、商品の販売部の人間・開発者・設計者の3者になります。
この時、商品というモデルは3者の間で同じ認識のものを共有することができます。

----商品モデル----
・商品名
・値段
・在庫
...

次に販売から配送までをシステムで管理する場合を想像します。関係者は先ほどの3者に加えて配送部の人間もかかわってくると思います。このとき、商品モデルに対して全関係者が同じ認識を持つことができるでしょうか。

★販売部の人間の認識
----商品モデル----
・商品名
・値段
・在庫
...

★配送部の人間の認識
----商品モデル----
・商品名
・配送先
・配送状況
...

上記からわかるように、同じ商品モデルでも関係者によって認識は異なります。
上記の認識を一つのモデルに無理やりまとめたとしても、

----商品モデル----
・商品名
・値段
・在庫
・商品名
・配送先
・配送状況

ごちゃごちゃしたモデルになってしまい、これを実際に設計からコードに落とし込むことは難しくなります。
また経理部や人事部の領域までシステム管理するとなるともうなにがなんだかわかりません。
システムが大規模になるにつれて、全関係者で認識を合わせることは難しくなっていることがわかります。

境界付けられたコンテキストを用いた分割

前述した、関係者が増えるにつれて認識の統一が難しくなってくることはどのようにドメイン駆動設計では解消することができるのでしょうか。そこで出てくるのが、本記事のタイトルにもある境界付けられたコンテキストです。ドメイン駆動設計では大きなシステムを「境界づけられたコンテキスト」に分割し、それぞれの中でモデル、言語の統一を実現し、関係者間での認識を揃えることができます。

まずコンテキストの意味は以下の通りです。
ITの分野では、利用者の意図や状況、環境などの総体を表したり、同じ処理や記述でも状況に応じて動作などが異なる場合に、その選択基準となる判断材料や条件などを指す場合が多い。
参照元 : e-words
こちらの記事も参考になるのでご確認ください。
プログラミングでよく見かける"コンテキスト(context)って何?

実際に例にあった商品の販売システムで考えてみます。境界付けられたコンテキストによる分割を行うと以下のようになります。

----販売コンテキスト----
・商品モデル
 ・商品名
 ・値段
 ・在庫
 ...

----配送コンテキスト----
・商品モデル
 ・商品名
 ・配送先
 ・配送状況
 ...

コンテキストを販売・配送と分割し、「販売コンテキスト」「配送コンテキスト」それぞれが一つの「境界づけられたコンテキスト」となっています。
それぞれのコンテキスト内で商品モデルが定義されているため、関係者の中で「商品モデル」の認識を統一することが可能になります。

まとめ

ここまで読んで境界付けられたコンテキストのイメージはついたでしょうか。
ドメイン駆動設計では前回の記事でも記載した通り、統一した認識のモデルを実際のコードに落とし込みます。価値あるソフトウェアを構築するために、関係者間で認識を合わせ、モデルを統一し実際にコードに落とし込むために、この境界付けられたコンテキストを理解する必要があると思います。
今後もドメイン駆動設計についてまとめていきます。参考にした記事も記載しますので、そこもおってみていただけると理解が深まると考えています。

次回は境界づけられたコンテキストを実装に落とすところまで記載しようと思います。

参考

境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説

ドメイン駆動設計入門 #1 ドメイン駆動設計とは

3
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?