ドメイン駆動設計は、ビジネスの主要ニーズに重点を置いてソフトウェアを開発するのに役立つ。だが、ドメイン駆動設計を実践するには、コンテキスト境界についての基礎を理解する必要がある。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
アーキテクトは、純粋なドメイン駆動設計(DDD:Domain-driven design)を自社に導入するのに苦労することが多い。DDDでは、複数の部署や複数のソフトウェアシステムにまたがってビジネスプロセスを対応付ける必要があるため、その複雑さから目的の成果を得るのが難しくなる。
とはいえ、ドメインモデリングはビジネスニーズを技術設計に置き換えるのに優れたアプローチだ。そのため、アーキテクトは、DDDの効果の決め手となるコンテキスト境界(bounded contexts)を定める方法を理解する必要がある。
ソフトウェア設計コンサルタントで書籍も執筆しているエリック・エヴァンス氏は、自身の著書『Domain-Driven Design:Tackling Complexity in the Heart of Software』(※)でコンテキスト境界について定義している。初めにエヴァンス氏は、複数のドメインからなる大きなビジネスドメインを、各ドメインをサポートする個別の基盤ソフトウェアシステムへ対応付ける際に、適切なコンテキスト境界がいかに役立つかを説明している。その意味では、コンテキスト境界とは、大きなソフトウェアシステムの複雑さを抑えるために必要なルールと境界を手引きするパターンだといえる。
(※)邦題:『エリック・エヴァンスのドメイン駆動設計、ソフトウェアの核心にある複雑さに立ち向かう』翔泳社
コンテキスト境界により、定義するドメインモデルが意味を成すことが保証される。コンテキスト境界の境目がどこになるかはそのシステムを利用する人々にとって明らかなはずだ。この境目が明確でなければ、非効率で複雑なドメインモデルが生み出される可能性がある。
Copyright © ITmedia, Inc. All Rights Reserved.