ドメインについて（４）
ドメイン分析を開始するにあたってドメイン辞書の作成、つまり語彙の収集を始めなければならない。
語彙は「解釈」と「関連」を持つ。そして語彙は一度定義すれば完了というものではない。改良され続ける事になる。
「意味」ではなく「解釈」としているのはシステム開発はチームによる協業である故である。一人しか開発者がいないのであれば「意味」でもよい。だがチームの場合、人により解釈が異なることがままある。ドメイン辞書には最初にその語彙を定義した者の「解釈」が記述されるが、別の者の「解釈」がより適切となればその定義に変更となることもある。
ドメイン辞書の作成とはアプリケーションドメインの語彙の文書化である。作成の目的は次のようなものである。
共通性分析ではドメイン辞書を作成する事から始める。ドメイン辞書にはそのアプリケーションの領域の語彙を文書化する。このようにする意図はこれから解決しようとする問題に絡む全ての側面を把握することだ。またそれと同時にソリューションの全ての側面も可能な限り把握するためである。問題を広く深く理解する前に顧客の言葉や要求を記述する文書の中から問題を一瞥するのである。また自分自身の経験もここで役立つだろう。このようなものを「ドメイン語彙」または「ドメイン辞書」と呼んでいる。これは古くからあるソフトウェア設計ツールの１つであるが現代の設計手法の中で再認識され始めている。
ドメイン辞書はその問題領域に於ける技術用語のカタログであり設計者はこのカタログに記載されている用語を使って作業を始める。ドメイン辞書は構造化設計技法をサポートするためのデータ辞書とは別物である。問題に初めてアプローチする時設計者が直面するのは目の前胃にあるニーズである。ソフトウェ開発の作業の大部分は明示された問題により発生する。そしてそのような問題は顧客自身の問題である。このようなニーズの性質からアプリケーションはその顧客の問題に特化したものになる。
「マルチパラダイムデザイン」より
ドメインについて（３）
システム開発にドメイン設計を導入する最大のメリットは凝集化である。ドメイン（ビジネス）に関わることを全て「ドメイン層」に閉じ込めることで高凝集システムとなる。
高凝集と低結合はどちらも重要な概念である。だが高凝集は低結合に比べこれまで議論される事が少なかった。これはそれだけ高凝集の価値が分かりにくい事を示しているだろう。グレーグラーマンは次のように指摘する。
オブジェクト指向開発では凝集性はクラスの責務がどの程度強く関係し収束されているかを示す基準です。関係性の高い責務を持ちあまり多くの作業をしないクラスは高凝集性を持ちます。凝集性の低いクラスは関係のない仕事をこなしたり仕事が大量になったりします。
「実践UML」より
凝集化はシステムの可読性、変更性、検証性、拡張性、そして再利用性は格段に向上する。凝集度はまた強度とも云われる。どれだけ同じ関心事を集めるかで凝集度が決まる。
凝集化の中でもビジネスという関心事を集めてグループの強度を上げていく行為をドメイン化と云い、その集合をドメイン層と云う。対してアプリケーション層は「ビジネス以外」に関わる集合である。この２つの集合は高凝集である。そして高凝集モジュールは他のモジュールとの結合度が低くなる。
ドメイン巣をインフラストラクチャ層とユーザインターフェース層から分離する事により各レイヤを遥かに明確に設計できるようになる。レイヤを明確にすると保守にかかるコストが格段に低くなるがそれは各レイヤーが別々の速度で進化して別々の要求に対応する傾向があるからである。このように分離することで分散システムにも配置し易くなる。別々のレイヤをそれぞれ別々のサーバやクライアントに柔軟に配置できるようにする事で通信のオーバーヘッドを最小化して性能を向上させる事ができるのだ。
「ドメイン駆動設計」より
だがこの凝集化、すなわちドメイン層の分離は知識と経験が必要である。思った以上に難しい。単純なシステムでさえ経験がなければ失敗するリスクが高い。 それ故小規模な開発ではドメインによる凝集化というアプローチが適さないこともある。
利口なUIパターンはユーザインターフェースにビジネスロジックを組み込む手法である。例えばユーザインターフェースでJavaScriptによるビジネスロジックプログラムを組み込むことがこれにあたる。凝集化とは真逆のアプローチだが、多くの小規模開発ではこの利口なUIパターンがしばしば「推奨」される。理由は次のケースでメリットがあるからである。
単純なアプリケーションの場合➡️単純なので分離しない方が生産性と保守性が高い。無理に分離すると逆に複雑になる。
有能な開発者がいない場合➡️レイヤ化のノウハウを学習する必要がない。レイヤ化の実践は開発者の育成と経験者による牽引がないと難しい。
ドメインについて（２）
「分析」とは何か。一般的な「分析」とは収集した情報を要素に分けて整理し、分析目的に合致した意味合い（メッセージ）を得ることである。システム開発に於ける「分析」も同様である。情報を分け、整理し、メッセージを得ること。だがシステム開発の現場では分析者が「分析」を正しく認識していないことは珍しくない。
実際そのような分析者にとって「分析」はクライアントとの話をそのまま要件定義書にトレースする行為にすぎない。これは本来の意味である「情報を収集し分けて整理し意味合いを見つける」という行為とは異なる。そのような分析によって作成された要件定義書は曖昧で複雑で不完全となる。
それでも通常の開発であれば曖昧さ、複雑さ、不完全さはレビューによって検知されるが、開発期間が十分でない場合、レビューがその役割を果たさない。そのため曖昧で複雑で不完全な要件定義書はそのまま設計工程、プログラム工程へと流れてしまう。
この問題の原因は分析者（或いはレビューア）の無知と怠惰である。
だが彼らはこう云い分けをする。
「クライアントの要求が曖昧で複雑なのだから要件定義書が曖昧で複雑になるのは仕方がない」
クライアントはただ、自分たちが活動しているドメインに於いて今後自分たちが関心がある事、そして実現したい事を話したいだけである。分析者がドメインに精通していればクライアントのイメージは伝わるはずである。然し勉強不足の分析者にそのイメージは伝わらない。故に完成したシステムは寿命の短いシステムとなってしまう。
よいシステムの分析対象はアプリケーションだけではない。アプリケーションドメイン、マーケットドメイン、企業ビジョンまでもが対象なのである。
ソフトウェア開発の実プロジェクトでの大半では極めて初期の段階から複数の開発コンフィグレーションの分岐を考慮する必要がある。単一システムのためにスタートしたプロジェクトであっても何らかの分岐の発生は通常の事で、マーケットが成長したり顧客のシステムに対する期待が拡がったりするとそれに合わせてプロダクトがカスタマイズされる。従って当面のアプリケーションを分析するだけでは十分とは云えない。分析の範囲をアプリケーションドメイン全体、さらにはマーケットドメイン、企業ビジョンにまで広げる必要がある。つまりアプリケーション分析ではなくドメイン分析を行いたいのである。ドメインとは何だろうか。”American Heritage Dictionary"によればドメインとは「活動・関心・機能の範囲、領域」のことである。ドメイン分析という言葉は基礎的なビジネス上の抽象を研究するということを意味する事が多い。例えばファイナンシャルトレーディングはドメインである。そのドメインの抽象の中にはトランザクション、株、債券、セキュリティ、先物取引、金融派生商品、外国株などが含まれる。また電話通信も一つのドメインである。呼び出しコール、電話、回線、リレー、加入者などがドメインの重要な抽象となる。ファイナンシャルトレーでイングや電話通信はアプリケーションドメインである。各々のアプリケーションドメインは１個のビジネス、企業、マーケットを定義し、我々はそこから完全なシステムのファミリを見つけ出す事ができる。「マルチパラダイムデザイン」より
ドメインについて（１）
ドメインとは、企業が定めた自社の競争する領域・フィールドのこと。事業ドメインともいう。
企業はドメイン（事業ドメイン）の設定により、戦う領域を設定し、組織活動の指針とする。ドメインは、企業の方向性を示す上で、非常に重要な意味を持つ。
例えば、ある鉄道会社がドメインを「鉄道事業」と定義した場合と「総合輸送事業」と定義した場合とでは、おのずと環境変化に対応する発想が変わってくる。「鉄道事業」と定義した場合は、輸送手段の進歩あるいは他の輸送手段との競合に対し、鉄道という枠の中でのみ差別化して優位に立つことを模索する。
一方、「総合輸送事業」と定義した場合は、経営環境の変化に対し、鉄道以外の輸送手段にも参入することにより競争優位を確立することを考える。つまり、他の輸送手段との競合を常に視野に入れた戦略を立てることになる。
ドメインを掲げることによって経営資源をフォーカスさせ、継続的に見ても経営資源を一貫して蓄積でき、組織全体として戦う方向性を定めることができる。
一方、ドメインを予め限定しないまま、多角化や買収を行って多様な事業分野に進出する企業もある。そういう状況においては、事業機会の拡大とともにドメインは次第に拡大する傾向にある。
設計そのものの目的は、ビジネス上のニーズを満たす事だ。そしてビジネス上のニーズはユーザの期待に左右される。成功はビジネスを十分に理解しているかにかかっている。ここでのビジネスはドメインと言い換える事もできる。システムを構築するという時、そのドメインのためにシステムを作成することになるのだ。しかし、設計の目的というのはそれだけではない。例を挙げよう。まず、設計は実装を導くためのものだ。その実装を分かり易く構築し易いものにするのは設計の責任である。（アインシュタインの言葉を言い換えて引用すれば、可能な限り作り易く、然しそれは以下にはならないように、）また、設計はシステム構築をするに足るものでなければならない。ここでいうシステムは時間の経過とともに拡張されて新しいマーケットや新しいアプリケーションにも適用できるものでなければならない。「マルチパラダイムデザイン」より
設計にはアプリケーション設計とドメイン設計がある。
アプリケーション設計はシステム寄りである。たいていのアプリケーション設計担当者はシステムに関してはよく知っているが、ビジネスには無関心である。一方、ドメイン設計はビジネス寄りである。たいていのドメイン設計担当者はビジネスに関してはよく知っているが、システムには無関心である。
２つの設計は対等ではない。設計の中心はドメイン設計である。ドメイン設計はビジネス要件をもとに行われ、ドメイン設計書にはビジネスの全てが網羅される。故に、ドメイン設計担当者はドメイン、すなわちビジネスに精通していなければならない。一方、アプリケーション設計にはビジネス要件は含まれないからアプリケーション担当技術者はビジネスを知らなくてもよいということになる。
ドメイン設計を導入するとシステムの凝集化が促進される。導入コストは安くないがその引き換えに得られる凝集化は大きい。エリックエバンスは次のように述べている。
オブジェクト指向プログラムでは、ユーザインターフェース（UI）、データベースおよびその他の補助的なコードが、ビジネスオブジェクトにビジネスオブジェクトに書かれる事はしばしばある。また、ビジネスオブジェクトが新たに追加されるときには、UIウィジェットやデータベーススクロプとの振る舞いに組み込まれてしまう。こういうことが起きるのは、短期的に見ると、動くようにするには最も簡単な方法だからだ。ドメイン関連のコードがこうした膨大な他のコードに拡散してしまうと、コードを見て意味を理解するのが極めて困難になる。ユーザインターフェースに対する表面的な変更が、実はビジネスロジックを変更する事もある。ビジネスルールを変更するために、ユーザインターフェースコードやデータベースコード、その他のプログラムコードを丹念に追跡しなければならないかもしれない。これでは、凝集度の高いモデル駆動のオブジェクトを実現するのは現実的ではなくなる。また自動化されたテストコードはぎこちないものになってしまう。全ての技術とロジックがそれぞれの活動に関連しているので、プログラムを非常にシンプルに保たなければ理解できなくなってしまう。「エリックエバンスのドメイン駆動設計」より
ドメイン設計をせずにアプリケーション設計を始めてしまうとビジネスの変化に対応できなくなる。その結果システムの寿命が短くなってしまう。
凝集化のメリットは再利用性、拡張性、可読性等の向上である。デメリットは初期コストだが、これは新しい事を始める際に避けては通れない道である。
SIerの組織レベルについて
プロジェクトが破綻する原因にトラックナンバー問題がある。知識が個人に独り占めされ様々なトラブルがおきるという問題だ。その人が事故や病気になれば破綻するし、或いはその人に問い合わせが集中して多忙になればチームは破綻する。これは個人が知識伝播しないことが悪いのではない。組織が知識伝播を支援しないことが悪いのだ。
では組織は知識伝播の支援をどのように実現すべきなのだろうか。それをSECIモデルで説明しよう。
知識というのは最初は人の頭の中にある。これを暗黙知という。
変換された形式知は伝播することができる。これにより知識は様々な人に広められる。
この流れをSECIモデルという。
SECIモデルを支援するのは組織の役目である。文書の間違いや曖昧さ、読みにくさを改修し管理することなどがそれである。組織は知識経路を追跡し技術者の知識レベルを分析する。組織により知識は適材適所にデリバリーされる。知識伝播はこうした組織の支援の元に達成される。
SIerは然しこうした支援に無頓着である。その姿勢を改めない限り彼等は今後も破綻プロジェクトを量産することになるだろう。
DIへの賛否
1.DIへの賛否
10年ほど前、DIはソフトウェア産業の問題を解決する銀の弾丸として喧伝され、それを実現するDIフレームワークのspringやseasarが登場した。DIはとても流行し最終的にはEJB3.0に取り込まれるまでになった。ではDIとは一体何者なのだろうか。
ここではDIの正体とDIがソフトウェア産業にもたらした功罪について考察する。
1.1.DIとは何か
DIとはDependency Injectionの略で直訳すれば依存性注入となる。そしてその正体は「オブジェクトの組み合わせをコントロールする仕組み」である。
〈図1〉
…
図1はUserがCoffeeImplを生成しないという意味だ。
次のソースコードを見て欲しい。
〈コード1〉
class User{
private Coffee coffee=new CoffeeImpl(); //①
public void drink(){
coffee.drink(); //②
}
}
coffeeにnew CoffeeImpl()を設定しているが、もしこのCoffeeImplがDBに依存しているならUserクラスの開発環境にもDBMSをインストールしなければならない。またテストする度にCoffeeImplが利用するテーブルのデータも再ロードする必要がある。
他に値をセットするメソッドもない。となればこのクラスは②で確実にNullPointerExceptionが起きてしまう。つまりバグである。
〈コード2〉
<component class="User">
<property name="coffee">
CoffeeImpl
</property>
</component>
意味はこうだ。
「Userロード時、coffeeにCoffeeImplのインスタンスをセットする」
もし設定ファイルがなければ①は
private Coffee coffee=new CoffeeImpl();
としなければならない。これではCoffeeImplに依存してしまう。
例えばCoffeeImplの内部でDBアクセスしている場合
ロード出来ない環境では動作確認出来ない。スタブとしてCoffeeImpl4TestをCoffeeImplの代わりに使いたい時にもUserクラスを修正し、動作確認が終わればまた元に戻さなければならない。
所がそのためには
上の設定ファイルの例ではCoffeeImplを設定しているが、
これによりUserクラスはCoffeeImplクラスへの「依存性」をソースコードに記述しないですむ。
設定ファイルにより「注入」できるため様々なメリットがあるのである。
