« MS、Groove Networkを買収 | メイン | Apache Incubatorオーバービュー »

ドメインに応じた開発環境を開発する

MSネタが続きます。前から書いているが、Micorosoftの目指している世界というのは、常に一歩先をみている。ただ、最近では、Javaのコミュニティ力に押されて、後手に回ってきていたように感じる(.NetのC#なんか)。しかし、ここにきて、盛り返し始めているもかもしれない。

次世代開発基盤技術“Software Factories”詳解 第1回 ソフトウェア工業化を目指してから。

代表的な開発手法(前述したプロトタイプ開発、ドメインクラス開発、プロダクトライン開発の3つ)の意思決定戦略を説明する。開発手法は単独で使うだけでなく、システムのレイヤ、分割したドメインにより、これらを複数組み合わせるのが現実的である。これらの開発手法では、開発規模(コード量、開発者数)により開発コストが変化するので、その開発規模が意思決定戦略の1つの基準となる

ようは、開発規模、開発レイヤ、ドメインにより、開発手法が柔軟に切り替わるべきだということだ。しかし、これは、アプリケーションアーキテクチャを複雑化し、要員スキルを上げてしまうことになりかねない。ていうか、実際、そうなりつつある。Javaでいえば、「プレゼンテーション」「ビジネスロジック」「データアクセス」という3層において、それぞれ異なるフレームワークや概念が導入されており、これらをすべて把握して的確なアーキテクチャを構成するとなると、かなりの知識が必要になる。これに加え、アプリケーションのライフサイクルで考えれば、仕様・変更管理、品質管理、デプロイなど、多岐にわたるアーキテクチャが存在する。

では、これを簡単にするためには、どうすべきなのかというのが、「Software Factories」というアイデアなのだと思う。ここからは、僕の言葉も混じるので、正確には原文をあたっていただきたい。

まず、アーキテクチャの実践については、プロダクトライン型、つまりIDEなどによって実践時に明確な制約を与えることで、柔軟性を犠牲にし、生産性を向上させることを前提にする。要求定義もIDEに組み込み、実装とは、機能ドリブンにダイレクレクトにリンクさせてしまう。
IDEには、実装・設計手法、つまりアーキテクチャを組み込むことになるが、当然のことながら採用されるアーキテクチャは、ドメインによって異なるべきだ。そこで、3つの手法を用意しておくことで、これを可能にする。


  1. パターン言語 : アーキテクチャのパターンカタログを作成し、パターンを選択することで設計ガイドラインを与え、実装への落とし込みを行う

  2. コンポーネント開発 : ロジックとプロセスを分離し、ロジックをコンポーネントとして、プロセスによって織り上げる。これにより、パターンを超えて、コンポーネントが共有できる

  3. ドメイン依存言語 : ドメインに特徴的な概念は、そのたびにアーキテクチャ化し、1として採用する

マイクロソフトの考えていることは、前からすごく明確で、開発者にいかに楽をさせるかということにつきる。VBやASPは、確かによいツールだが、汎用的過ぎて、それぞれのドメインで最適な能力を発揮できたとは思えない。そのため、Javaのように、アーキテクチャの細分化による最適化というアプローチは、先端を行く開発者には受け入れられている。しかし、それが進みすぎることで、大半の開発者が追いつけなくなってきていることも確かだ。そこで、IDEによる容易なアプローチという部分は残しつつも、それぞれのドメイン、コンテキストに応じて、柔軟にアーキテクチャを組み変えればよいと考えたのだと思う。

以前エントリしたPOJOがしめすアプリケーションの新しい形というものと、実現しているアプリケーションは変わらない。ただし、開発プロセスにおいて、そのアーキテクチャをどう実践するのかという点は、踏み込んで書けていなかった。とはいえ、Javaでも同じような動きがある。Eclipseに、ドメインに応じたプラグインを開発するというのがその1つだろう。これは、間違いなく流行する。

こう考えると、Javaとマイクロソフトは、行く道は違うが、同じゴールを目指しているように感じる。まだ、いろいろ書きたいのだが、整理が付いていないのでこのぐらいにしておく。なんにせよ、これからのアプリケーション開発では、「ドメインに応じた開発環境を開発する」つまり、そのアプリケーションに最適なアーキテクチャを明確に決定し、固定化するという作業が入ってくることだろう。

ついでになるが、IDE(統合開発環境)という言葉は、実は気に入らない。アプリケーションのライフサイクルで最も重要なのは、使用中・運用中だ。こうしたドメインごとのアーキテクチャを明確化されたツールは、使用中・運用中にこそ有効なはずだ。だから、アプリケーションライフサイクル環境(Application Lifecycle Environment)という言葉あたりが正しいと思う。

トラックバック

このエントリーのトラックバックURL:
http://www.arclamp.jp/mt33/mt-tracback.cgi/1420

この一覧は、次のエントリーを参照しています: ドメインに応じた開発環境を開発する:

» EoDフレームワーク? 送信元 天使やカイザーと呼ばれて
お風呂で考えたことを書いてみる。 最近,EoDについて考える機会があった。「Easy Of Development」,つまり「開発を簡単に」という言葉だ。とかく世の中では,EJB3.0や,J2SE5.0に搭載されたAuto-Boxingやannotation,JSFなどがEoDとして取り上げられているが,システム凱.. [詳しくはこちら]

コメントを投稿

(いままで、ここでコメントしたことがないときは、コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)

About

2005年03月21日 12:36に投稿されたエントリーのページです。

ひとつ前の投稿は「MS、Groove Networkを買収」です。

次の投稿は「Apache Incubatorオーバービュー」です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Creative Commons License
このブログは、次のライセンスで保護されています。 クリエイティブ・コモンズ・ライセンス.
Powered by
Movable Type