たなかこういちの開発ノート

システム開発に携わる筆者が、あれこれアウトプットするブログ

「サブジェクト指向」について(私的実践DDD、その4)(1 of 2)

(※前回からの続きです。)
 
「サブジェクト指向」の考え方は、オブジェクト指向分析・設計における「関心の分離」に関わる一つの方策として古くから提唱されているものです。人によって多少ニュアンスに違いがありますが、私はおおよそ下記記事が説明するところの「サブジェクト指向」で理解しています。
 
@IT、「次世代開発基盤技術“Software Factories”詳解」-「第4回 フィーチャの実現法とサブジェクト指向パラダイム」-「可変性を実現する先進的な開発手法「サブジェクト指向パラダイム」」:
 
これは2005年の記事です。なお「サブジェクト指向」でググると、OLAP、DWH用語としての「サブジェクト指向」についての記事がたくさん見つかります。ちょっと似ていますが、それらは関係ありません。ここではOOにおける「関心の分離」に関わる「サブジェクト指向」がテーマです。
 
〜・〜
 
サブジェクト指向の理解
 
サブジェクト指向はあくまでオブジェクト指向の派生形の一つです。そこで、サブジェクト指向を踏まえたOOと踏まえて無いOOを区別するために、サブジェクト指向を踏まえて無いOOを「古典的OO」と、ここでは表現することとします。
 
ある卸業の業務分析で、例えば「受注」、「商品」、「得意先」、というエンティティ(※DDD的には集約、とした方がよいでしょう)が見出されたとします。また、アクターとして「注文受付オペレーター」と「販売管理担当」が見出されたとします。
 

f:id:tanakakoichi9230:20150802022928p:image

図1.業務分析で見出されたエンティティとアクター
 
古典的OOでは、集約「受注」が一つ見出される事実から、「受注サブドメイン」が一つだけ存在すると考えます。「注文入力」という受注エンティティの新規作成機能(注文受付オペレーター向け)と、「受注確定」という更新機能(販売管理担当向け)があるとしたら、両者を一つの「受注」エンティティ(もしくは集約)もしくはドメインサービスに装備します。
 

f:id:tanakakoichi9230:20150802022952p:image

図2.古典的OOにおける「受注サブドメイン」の認識
 
サブジェクト指向では、確かにデータの存在としては「受注」は一種類なのですが、注文受付オペレーター観点と販売管理担当観点で、「受注サブドメイン」に対する要件が異なっていることに注目します。
 
例えば、「注文入力」という新規作成機能は、注文受付オペレーターにのみ必要とされています。「注文入力」における受注エンティティには、入力項目「取引条件」は必要ですが、項目「納品予定日」は不要でしょう。対して販売管理担当には「注文入力」機能は不要で、一方で(在庫引き当て後の)「受注確定」機能が必要とされます。「受注確定」における受注エンティティには、「注文入力」では不要だった項目「納品予定日」や「支払期限」が必要とされるでしょう。
 

f:id:tanakakoichi9230:20150802022937p:image

図3.サブジェクト指向における、二つの「受注サブジェクト」の認識
 
サブジェクト指向では、要求される機能や項目が異なるならば、注文受付オペレーター観点の「受注」と販売管理担当観点の「受注」とは、異なるサブドメインであると捉えてしまった方がよい、と考えます。古典的OOにおいては同一のひとつのサブドメインと捉えられるもの/捉えるべきとされるものを、アクターの観点などから異なるサブドメインと捉える場合、それを「サブジェクト」と称します。
 
 
おさらいします。古典的OOでは、データの存在から、例えば「受注サブドメイン」が一つ見出されます。サブジェクト指向では、この一つの「受注サブドメイン」が、アクターの観点から、「注文受付オペレーター観点の受注サブジェクト」と「販売管理担当観点の受注サブジェクト」の二つに分けられる、と捉えます。なお、サブジェクト指向においても、「受注サブドメイン」の語は、この二つの関連するサブジェクトを束ねる概念として引き続き用いられます。(※サブジェクトは、サブドメインの語を用いるならば“マイクロ・サブドメイン”とでも表現されるような存在です。多分にマーケティング的なネーミングですが。。)
 
UMLユースケースで、関連するユースケースを一つに束ねたものを「サブジェクト」と言っています。これは実際、サブジェクト指向における「サブジェクト」の概念を適用してのことと解されます。先の例に基づけば、ユースケース「受注入力」を含むような「注文受付オペレーションサブジェクト」と、ユースケース「受注確定」を含むような「販売管理サブジェクト」が描かれるでしょう。つまり、ユースケース分析結果と一対一対応するようにサブドメインを切ったとき、そのサブドメインをやはり「サブジェクト」と称することとする、と言うこともできます。
 
DDDの「境界付けられたコンテキスト」は、「サブジェクト」か?
 
「実践ドメイン駆動設計」を読む限り、答えは"Yes"と云えると判断します。2章11節の前半、出版社における「書籍」の扱いを例に説明している箇所から引用します。
 
DDDでのモデリングの際には、書籍のライフサイクルの段階ごとに、別の境界づけられたコンテキストを利用する。これら複数の境界づけられたコンテキストのそれぞれに、書籍を表す型を用意する。これらの書籍オブジェクトにはおそらく識別子があって、それをコンテキスト間で共有するのだろう。識別子が確定するのは、おそらく最初の起案段階だ。しかし、識別子は共有するものの、各コンテキストにおける書籍のモデルはすべて異なる。それで全然かまわないし、むしろそうあるべきだ。ある境界づけられたコンテキストに関わるチ ームが書籍のことについて話すとき、それはまさに、そのコンテキスト内で必要となる意味合いで使われることになる。組織内の各地には、それぞれ別のニーズがあるということを受け入れよう。
 
明らかに、1)「書籍」には複数種類あると認識するのが妥当だということ、2)「書籍」の意味が異なるなら、異なる境界付けられたコンテキストを設けるべきこと、を言っています。このような、要求・要件の観点から似て非なる「書籍」が認められるなら、それぞれに対して(異なる境界付けられたコンテキストだとして)異なるサブドメインを設ける、というような設計手法を「サブジェクト指向」と言います。サブジェクト指向に基づくサブドメインは、「サブジェクト」であるという事ができます。
 

f:id:tanakakoichi9230:20150802023004p:image

図4.「サブジェクト」=「境界付けられたコンテキスト」
 
古典的OOとサブジェクト指向のアーキテクチャーのイメージ比較
 
古典的OOでは、例えば「受注サブドメイン」が見出されたとき、「受注」に関わる機能の装備先となるエンティティまたは集約もしくはドメインサービス等を抽象して「ドメイン・オブジェクト」または(文脈を踏まえつつ)単に「オブジェクト」と称する事があります。業務の操作対象としての唯一の「受注」がいわゆる“オブジェクト”として「でん」っと鎮座しているイメージです。
 

f:id:tanakakoichi9230:20150802023031p:image

図5.古典的OOの構築様式のイメージ
 
サブジェクト指向では、「受注」関連の複数のサブジェクトが、おおよそ正多角形を描くように円陣を組むように配置されているイメージです。業務の操作対象物たる“オブジェクト”が中心に厳然とあるというよりも、業務の各局面を個別に表現している“サブジェクト”のふわっとした集合物、が実体です。
 

f:id:tanakakoichi9230:20150802023017p:image

図6.サブジェクト指向の構築様式のイメージ
 
◆以上
(※次回へ続きます。)