2008年への投企 (1)
人間とは、未来へ向けて自らを投企していく存在である。ということで、今年最初のエントリでは、ソフトウェア開発に関して、新しく迎えた2008年の展望を予想してみたい。
今年はDSL普及元年
DSLは以前から話題に上ってはいるが、実際に恩恵に与っているのはまだ一部のRails開発者くらいなのではないかと思う。いまMartin Fowlerがすごい勢いで次の本を書いていて、そのタイトルが『Domain Specific Languages』のようだ。
http://martinfowler.com/dslwip/
このDSL本が年内に出版されるとすれば、PofEAAによってエンタープライズアプリの開発が一気に整理されたように、DSLの使用が一般のエンタープライズアプリ開発の現場まで降りてくるかもしれない。
いずれにせよDSL自体は古くからあった技術で、それだけでは面白みは少ない。期待されるのは、ドメイン層でのDSL(ビジネスDSL?)が普及することだ。DDDを突き詰めていくと、1つにはビジネスDSLのような世界が広がっていくと私は思っている。
DDDのボキャブラリが日本でも浸透しはじめる
DDDは出版からもう4年以上経ったが、そろそろ日本でもその基本的なボキャブラリ(ユビキタス言語、エンティティ、値オブジェクト、リポジトリ、仕様、コンテキストマップ、中核ドメイン、責務の階層・・・)が浸透しないかと、淡く期待している。
昨年は責務駆動設計の本『オブジェクトデザイン』もついに翻訳されたので、今年こそ責務や高凝集/低結合など、原理・原則に立ち戻ったオブジェクト指向の考え方が見直される年になってほしい。yojik氏が「今年はオブジェクト指向ルネッサンスの年だ」と言っているので、ぜひ一緒に盛り上げて行きたい。
ドメインフレームワークとしてのワークフローエンジン、ルールエンジンへ
ワークフローエンジンやルールエンジンはこれまでSOAの文脈で語られることが多く、そのため導入の敷居が高かったが、個人的には単なるビジネスロジック実装用のミドルウェア(ドメインフレームワーク)として考えた方がいいと思っている。
DDDのEric Evansは、ドメインロジックの一部は「プロセス」「制約」「仕様」といったカテゴリに分類できると言っているが、プロセスは正にワークフローエンジンで実装できるし、制約、仕様はルールエンジンの範疇に入る。
動向として面白いのは、JBoss Seam だ。Seam は JSF と EJB3 だけでなく、jBPM や Rules との連携までシームレスにやってくれる。Seam のサンプルには、jBPM を使って Spring Web Flow のような画面フローの制御を行う例や、Rules を使ってセキュリティ機構を実装する例が用意されている。他のアプリケーションフレームワークは、ワークフローエンジンやルールエンジンと連携する方法を、Seam から学ぶべきだと思う。
まだまだ予想したいのだが、長くなってきたので続きは次のエントリへ。
今年はDSL普及元年
DSLは以前から話題に上ってはいるが、実際に恩恵に与っているのはまだ一部のRails開発者くらいなのではないかと思う。いまMartin Fowlerがすごい勢いで次の本を書いていて、そのタイトルが『Domain Specific Languages』のようだ。
http://martinfowler.com/dslwip/
このDSL本が年内に出版されるとすれば、PofEAAによってエンタープライズアプリの開発が一気に整理されたように、DSLの使用が一般のエンタープライズアプリ開発の現場まで降りてくるかもしれない。
いずれにせよDSL自体は古くからあった技術で、それだけでは面白みは少ない。期待されるのは、ドメイン層でのDSL(ビジネスDSL?)が普及することだ。DDDを突き詰めていくと、1つにはビジネスDSLのような世界が広がっていくと私は思っている。
DDDのボキャブラリが日本でも浸透しはじめる
DDDは出版からもう4年以上経ったが、そろそろ日本でもその基本的なボキャブラリ(ユビキタス言語、エンティティ、値オブジェクト、リポジトリ、仕様、コンテキストマップ、中核ドメイン、責務の階層・・・)が浸透しないかと、淡く期待している。
昨年は責務駆動設計の本『オブジェクトデザイン』もついに翻訳されたので、今年こそ責務や高凝集/低結合など、原理・原則に立ち戻ったオブジェクト指向の考え方が見直される年になってほしい。yojik氏が「今年はオブジェクト指向ルネッサンスの年だ」と言っているので、ぜひ一緒に盛り上げて行きたい。
ドメインフレームワークとしてのワークフローエンジン、ルールエンジンへ
ワークフローエンジンやルールエンジンはこれまでSOAの文脈で語られることが多く、そのため導入の敷居が高かったが、個人的には単なるビジネスロジック実装用のミドルウェア(ドメインフレームワーク)として考えた方がいいと思っている。
DDDのEric Evansは、ドメインロジックの一部は「プロセス」「制約」「仕様」といったカテゴリに分類できると言っているが、プロセスは正にワークフローエンジンで実装できるし、制約、仕様はルールエンジンの範疇に入る。
動向として面白いのは、JBoss Seam だ。Seam は JSF と EJB3 だけでなく、jBPM や Rules との連携までシームレスにやってくれる。Seam のサンプルには、jBPM を使って Spring Web Flow のような画面フローの制御を行う例や、Rules を使ってセキュリティ機構を実装する例が用意されている。他のアプリケーションフレームワークは、ワークフローエンジンやルールエンジンと連携する方法を、Seam から学ぶべきだと思う。
まだまだ予想したいのだが、長くなってきたので続きは次のエントリへ。