ドメインについて（１）
ドメインとは、企業が定めた自社の競争する領域・フィールドのこと。事業ドメインともいう。
企業はドメイン（事業ドメイン）の設定により、戦う領域を設定し、組織活動の指針とする。ドメインは、企業の方向性を示す上で、非常に重要な意味を持つ。
例えば、ある鉄道会社がドメインを「鉄道事業」と定義した場合と「総合輸送事業」と定義した場合とでは、おのずと環境変化に対応する発想が変わってくる。「鉄道事業」と定義した場合は、輸送手段の進歩あるいは他の輸送手段との競合に対し、鉄道という枠の中でのみ差別化して優位に立つことを模索する。
一方、「総合輸送事業」と定義した場合は、経営環境の変化に対し、鉄道以外の輸送手段にも参入することにより競争優位を確立することを考える。つまり、他の輸送手段との競合を常に視野に入れた戦略を立てることになる。
ドメインを掲げることによって経営資源をフォーカスさせ、継続的に見ても経営資源を一貫して蓄積でき、組織全体として戦う方向性を定めることができる。
一方、ドメインを予め限定しないまま、多角化や買収を行って多様な事業分野に進出する企業もある。そういう状況においては、事業機会の拡大とともにドメインは次第に拡大する傾向にある。
設計そのものの目的は、ビジネス上のニーズを満たす事だ。そしてビジネス上のニーズはユーザの期待に左右される。成功はビジネスを十分に理解しているかにかかっている。ここでのビジネスはドメインと言い換える事もできる。システムを構築するという時、そのドメインのためにシステムを作成することになるのだ。しかし、設計の目的というのはそれだけではない。例を挙げよう。まず、設計は実装を導くためのものだ。その実装を分かり易く構築し易いものにするのは設計の責任である。（アインシュタインの言葉を言い換えて引用すれば、可能な限り作り易く、然しそれは以下にはならないように、）また、設計はシステム構築をするに足るものでなければならない。ここでいうシステムは時間の経過とともに拡張されて新しいマーケットや新しいアプリケーションにも適用できるものでなければならない。「マルチパラダイムデザイン」より
設計にはアプリケーション設計とドメイン設計がある。
アプリケーション設計はシステム寄りである。たいていのアプリケーション設計担当者はシステムに関してはよく知っているが、ビジネスには無関心である。一方、ドメイン設計はビジネス寄りである。たいていのドメイン設計担当者はビジネスに関してはよく知っているが、システムには無関心である。
２つの設計は対等ではない。設計の中心はドメイン設計である。ドメイン設計はビジネス要件をもとに行われ、ドメイン設計書にはビジネスの全てが網羅される。故に、ドメイン設計担当者はドメイン、すなわちビジネスに精通していなければならない。一方、アプリケーション設計にはビジネス要件は含まれないからアプリケーション担当技術者はビジネスを知らなくてもよいということになる。
ドメイン設計を導入するとシステムの凝集化が促進される。導入コストは安くないがその引き換えに得られる凝集化は大きい。エリックエバンスは次のように述べている。
オブジェクト指向プログラムでは、ユーザインターフェース（UI）、データベースおよびその他の補助的なコードが、ビジネスオブジェクトにビジネスオブジェクトに書かれる事はしばしばある。また、ビジネスオブジェクトが新たに追加されるときには、UIウィジェットやデータベーススクロプとの振る舞いに組み込まれてしまう。こういうことが起きるのは、短期的に見ると、動くようにするには最も簡単な方法だからだ。ドメイン関連のコードがこうした膨大な他のコードに拡散してしまうと、コードを見て意味を理解するのが極めて困難になる。ユーザインターフェースに対する表面的な変更が、実はビジネスロジックを変更する事もある。ビジネスルールを変更するために、ユーザインターフェースコードやデータベースコード、その他のプログラムコードを丹念に追跡しなければならないかもしれない。これでは、凝集度の高いモデル駆動のオブジェクトを実現するのは現実的ではなくなる。また自動化されたテストコードはぎこちないものになってしまう。全ての技術とロジックがそれぞれの活動に関連しているので、プログラムを非常にシンプルに保たなければ理解できなくなってしまう。「エリックエバンスのドメイン駆動設計」より
ドメイン設計をせずにアプリケーション設計を始めてしまうとビジネスの変化に対応できなくなる。その結果システムの寿命が短くなってしまう。
凝集化のメリットは再利用性、拡張性、可読性等の向上である。デメリットは初期コストだが、これは新しい事を始める際に避けては通れない道である。
