Help us understand the problem. What is going on with this article?

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

More than 1 year has passed since last update.

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

公式DDD 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.
境界付けられたコンテキスト
特定のモデルを定義・適用する境界を明示的に示したもの。
代表的な境界の例は、サブシステムやチームなど。

まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。
境界付けられたコンテキストは、2つの観点から解説が必要でしょう。

・概念としての境界付けられたコンテキスト
・境界付けられたコンテキストをどう実装に落としこむか

今回の記事では、概念の方の説明をしたいと思います。

概念としての境界付けられたコンテキスト

モデルの共有

ドメイン駆動設計の定義についてEric Evansはなんと言っているのか

こちらの記事で書いた通り、DDDではすべての人(ソフトウェア開発者、ドメインエキスパート)が同じ意味で言葉を使うことを目指します。

例えば、ECサイトで商品を販売するシステムを考えてみましょう。ここでは、エンジニアと販売管理する人たちの中で、「商品」に関しては同じモデルを共有します。

image.png

エンジニアと販売部のコミュニケーションがうまくいき、「商品」について同じモデル、言葉を共有することができました。

では、販売から配送までをシステム管理したくなったとします。

image.png

おっと、配送部の人は「商品」と言った時に全く別のものをイメージすることがわかりました!

DDDではすべての人が同じ意味で言葉を使うことを目指すのではなかったのでしょうか?

それでは強引に、「商品」の概念を統一しましょう。

image.png

『「商品」は売値、在庫数、配送先、配送状況を持ちます』・・・?

なにやらややこしくなってきました。さらに、DDDではこれをコードに落とし込むことを目指すので、「商品」の振る舞いを「商品」クラスに詰め込んでいくことに・・・上手くいくイメージが湧きますか?

さらに、請求の管理までをシステム化することになり、カウンターパートとして経理部の人も増えました。当然、経理の人は「商品」に関して違うイメージを持っています。

image.png

さて、すべての人が同じ意味で言葉を使うことを目指す・・・ことは可能でしょうか?

そう、システムが大規模になると、関係者すべてで統一したモデルを作ることは難しくなるのです。

エリック・エヴァンスのドメイン駆動設計で以下のようなことが語られています。

In those younger days we were advised to build a unified model of the entire business, but DDD recognizes that we've learned that "total unification of the domain model for a large system will not be feasible or cost-effective"
昔はビジネス全体の統一モデルを構築するようにアドバイスされていたが、DDDは、「大規模システムのドメインモデルの完全な統合は実現不可能で、費用対効果が低い」と認識しています

そこで、DDDでは大きなシステムを「境界付けられたコンテキスト」に分割し、それぞれの中でモデル、言語の統一を目指すのです。

境界付けられたコンテキストによる分割

image.png

コンテキストを分割することができました!「販売コンテキスト」「配送コンテキスト」それぞれが一つの「境界付けられたコンテキスト」になります。

それぞれのコンテキスト内では、関係者の中で「商品」は必ず同じモデル、用語で統一します。この範囲でなら、モデル、用語を統一することは現実的になりそうですね。

コンテキストマッピング

さて、販売と配送を別のコンテキストとして定義し、「商品」を別のモデルにしましたが、現実的には「商品」は繋がっています。

ということは、このコンテキストをまたいで「商品」をどう扱うかを決めないといけません。

このようなコンテキスト同士の関係性を簡単な図で表すことを、コンテキストマッピングと言います。

image.png

このように
1.モデリング対象を境界付けられたコンテキストで分割する
2.コンテキスト同士の関係をマッピングする
という手順を踏むことが、DDDの第一歩です。

なぜなら、DDDでは、「ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する」ことを目指しますが、「モデル」はまず適用するコンテキストを区切らないと定義できないからです。

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

さて、ここまでで概念はおわかりいただけたと思います。

ただ、「言いたいことはわかった、でも結局どうやって実装するのか全然わからないよ」という状況ですよね?

次の記事ではその実装について書きたいと思います。お楽しみに!

DDD連載記事

なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか
ドメイン駆動設計の定義についてEric Evansはなんと言っているのか
モデルでドメイン知識を表現するとは何か
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か
ドメイン駆動 + オニオンアーキテクチャ概略
モデルとは"現実世界を正しく表現したもの"ではないという話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話

little_hand_s
当面はDDDを探求していきたい所存。
http://little-hands.hatenablog.com/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away