  |
システムを定義する場合、そのシステム「どのような機能」を持つかと、その機能を「どのように実現する」か。という二つに分かれる。
前者は、アプリケーションドメインと呼び、後者をソリューションドメインと呼ぶ。
抽象化された論理的な設計はアプリケーションドメインに含まれ、ソリューションドメインは言語や環境に適応させた実体になる。
少し前、システムはソリューションドメインのみを実現したモノとして扱われ、そこにオブジェクト指向を組み合わせることが多かった。
ただ似ているという理由で、継承が行われることが多発した。「オブジェクト指向がそのまま、ごちゃまぜになって散り散りに流出した。」
というか、そもそもアプリケーションドメインって考えが無かった。それが設計書との乖離を産みスパゲッティコードが増えた。
オブジェクト指向で最初に学ぶ継承が、ポリモーフィズム（多様性）を実現するための１つの特性でしかないのに
「継承のためにオブジェクト指向を使っても良い」という誤った考えが、勘違いの原因だろう。
この問題は、最近では結構認知されてるのだが、実際の現場では、打開策を模索中な場合が多い。
近年のアプローチは、システム上でもアプリケーションドメインは表現されるべきという考えである。
打開策としては、このアプローチによる実績を増やしていくこと。
設計が上手くいったところで外からみたシステムの評価は大きく変わらない。 結局のところ、マーケティングから潜在的欲求を分析して、求められてるシステムを提供するのが本質であ...
設計の良し悪しで機能の追加とか修正とかのコストが全然違ってくるから、 要求の変化にどれだけ機動的に対応できるかという観点でシステムを評価したら設計も重要になってくると思...
たしかに、機能拡張性というのもオブジェクト指向の売り文句の一つでした。 今は、理想的な設計はやっぱり現実問題難しいので、設計も柔軟に変えていくってアプローチの方が多いか...
14 
11 
8 
28 
36 
23 
8 
20 
