InfoQ

News

ビジネスロジックとテクノロジを離して考える: Kathleen Dollard氏のコード生成における新たな見解

作者 Sadek Drobi, 翻訳者 編集部 投稿日 2007年12月27日 午前12時21分

コミュニティ
.NET,
Architecture
トピック
プログラミング,
Domain Specific Languages
タグ
Code Generation,
BDD

ビジネスロジックをユーザインターフェースから区分することはVisual Basicが私たちに教えた大切な教訓の一つである。Kathleen Dollard氏は、新たな技術が出現した時に全てを再記述するのを防ぐためにビジネスロジックをどんなテクノロジーからも区分するべきである事を論じてい る。そして、Kathleen氏によるとコードはテクノロジであるので、ビジネスの知識をもそれから隔離する必要があるようだ。

ビジネスロジックをどんなテクノロジと統合しても、新たなテクノロジーが誕生した時に全てを最初から再記述することは避けられない。-そしてコードはテクノロジなのである。

・・・コードとビジネスロジックと統合することはできません。

もっとも輝かしく、美しいおもちゃと言語は未来に残る遺産なのです。

ビジネス知識はむしろ”それが属すべきところに保管されるべきである。データベースストラクチャ、サービスコントラクト、テスト定義、ロジックルール、 ワークフロー、ビジネスオブジェクトコード、検証ルール、承認ガイドライン、ユーザインターフェース、等である。”。しかしながらビジネス情報をどこに隔離するかに関わらず、それは未だに変化から逃れられないテクノロジに基づいているのだ。いずれにせよ、”意図を表現する核心的な方法として”コードを使用す るのと与えられたシンタックスで意図の表現を保存するのには重要な相違点が一つある”

変化する宣言を認識しカテゴライズすることができる。もちろん宣言のシンタックスはそのためのテクノロジーに基づいている。しかし、有能なメタデータはどんなものでも他のどんなメタデータシンタックスにでも変換されることが可能である。

私達が従事している良く知っている仕事をきちんと区分けすることによって、私達は次世代においてそれを使用することもできるし、しないこともできる。

このようにしてKathleen氏は、ビジネスロジックをコードから抽出して隔離するための方法としてコード生成を推奨している。彼女の経験に基づいて自身は” ベストな開発を行っても、ほどほどのコード生成開発よりも劣っているのです。”と述べている。Agile方法論を使用している最も専門的なチームは、時間どおりに高品質のソフトウェアを納品することができるのだが、Katheleen Dollard氏にとっては”新たなテクノロジで最初からやりなおさなければいけない”ので、それを成功とは呼べないのである。

生成されたシステムの中でコードが大変重要な役割を果たすことに重点を置くのは大切である。バグをマップできないのは80年代の4GL災害の理由の一つだった。生成されたコードは”システムがどのような事が起こっているかをあなたに伝える”事そのものなので、その落とし穴を避けることができる。それはデ バッグにおいては絶対的に欠かせない。それゆえにKathleen氏はコードを”不可欠な悪者”として描き、そのように扱われるべきであることを論じた。

また彼女はそのようなアプローチはコード生成を行うのを可能にする適切なツールと同様に、プログラミングと重要なリーダーシップに対する私達の考え方に根本的な移行が求められることを強調した。Kathleen氏は今日”.NETはテクノロジの変化からあなたのテクノロジを守ってくれるものではありません。”と論じている。それは実のところそのペースを加速するのだ。しかしながらコード生成のより広範囲の使用における仮説が既にいくつかある。

メタデータかもしくはXMLリテラルへのマッピングのためのエンティティフレームワークは、Kathleen Dollard氏によると、”コード生成の素晴らしい可能性”と”複雑な生成のためにXSLTを置き換えるポテンシャル”をも備えているそうだ。また Kathleen氏は数年後にコード生成の範囲がとても活発になることを期待している。これが彼女が信じるところの、”書くのが無駄な全てのもののためのコード生成と、書く必要性のある全てのコードのための非常に変化したBDDのコンビネーションに基づいた適切な開発に私達を近づける"ということだろう。

原文はこちらです:http://www.infoq.com/news/2007/12/code-generation-for-business

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

特集コンテンツ一覧

トップスポーツチームの監督に教わる秘訣

この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。

事例研究:Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト

この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。

Agile2008チーム参加レポート - 帰国そして変化

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。

SilverlightとJavaのインターオペラビリティ

マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。

Agile2008 チーム参加レポート - カンファレンス参加編

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。サブミッションが選択された人、そうでない人も含めて、個々の目的意識の確認、膨大なプログラムから聞きたいセッションの選択、旅行の準備、プレゼンテーションの準備の期間を終えて、無事当日を迎えました。

Agile2008 チーム参加レポート - 動機/準備編

筆者はアジャイルソフトウェア開発についての年に一度の国際会議であるAgile2008に初めて参加してきました。今年の日本からの参加者の数は14名にも及び、発表者は5名、受け持ったセッションは8つに及び、例年にない活躍を見せました。なぜ今年のAgile2008では、これほど多くの日本人が参加し発表に至ったのか? そのレポートをお届けします。

Javaトラブルシューティングメルマガ総集編 2008/08~09

エスエムジーでは、Java全般を対象にしたトラブルシューティングサービス「JaTS」を提供しています。この記事では、前回に引き続き、JaTSにて蓄積したトラブル事例とその解決ノウハウの一部をお送りしている「Javaトラブルシューティングメールマガジン」(JTSMM)の総集編として、過去2ヶ月のトラブル事例と追加情報をダイジェストとして提供いたします。

モデル駆動アプローチがうまく機能しない(しなくなる)8 つの理由

この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。