Closing the Gap – DDD, MDD, DCI and Codegeneration

Johan den Haan さんのつぶやきで参照していたスライドです。 モデリングとコード生成に関心のある人にとって、中々興味深い内容です。

  1. Closing the Gap – DDD, MDD, DCI and Codegeneration
広告
Closing the Gap – DDD, MDD, DCI and Codegeneration

DSL development: 7 recommendations for Domain Specific Language design based on Domain-Driven Designについて

Johan den Haanさんのブログポストです。

  1. DSL development: 7 recommendations for Domain Specific Language design based on Domain-Driven Design

DSLのLifecycleという話題を説明した後でDSL設計について彼の経験に基づいたアプローチを説明しています。 これまで良くあったDSL設計テクニックの説明ではなく、少し距離を置いた視点で全体を押さえようと試みている点、好感が持てます。 DSLにご関心のある方に一読をお薦めします。

DSL development: 7 recommendations for Domain Specific Language design based on Domain-Driven Designについて

Java Domain Driven Frameworks reviewについて

Java never die というタイトルのブログに興味深いエントリが掲載されています。

  1. Java Domain Driven Frameworks review

7件のJava Domain Driven Frameworkをあげ、実際にサンプル実装をしながらこれらを比較しようとしています。 個人的に気になり過去に調べたことのあるものが幾つか含まれています。 新しい Java 用 Framework などを評価する際にも参考になりそうです。

Java Domain Driven Frameworks reviewについて

MashupとSOAについて

前回のポストではSOAとDDDそしてプロセスの関係について感想を書きましたが、今回はそこにMashupを追加したいと思います。

Mashupという言葉自体は中立的な言葉ですが、実際は個別に使えるサービス(Webサービス等)を簡単に組み合わせ意味のあることを実現するものだと思います。一例としてYahoo Pipesを取り上げます。これがデビューした時に幾つか作って遊んでみたのですが、例えば気になるRSS Feedの出力をフィルタにつなぎそれを出力するといった「ダイアグラムを使ったプログラミング」が出来ます。UnixのPipeにヒントを得たことは確かで、そういう背景を持つプログラマも多数参加しています。しかし同時に、まったくそういう背景を持たない一般ユーザも結構いるということです。何しろ簡単で役に立ちますから。

Pipesで出来ることを良く考えてみると、利用できる各種サービスと(Mashupの)制御構造の部品が提供されていてそれをワイヤリングするというものです。得たい情報を得ると言う目標(Business Objective)を達成するために、(意識するかどうかは別として)プロセスをユーザに定義させ、そのプロセスの中から「利用できる各種サービス」というサービスを使う、言い換えるとサービスを組み合わせてプロセスを実現する仕組みになります。このあたりが前ポストの話題に近いことが分ると思います。この各種サービスは当然SOAのサービスでも良い訳です。そして一般ユーザがサービスとして意識するのは主にビジネスサービスであり、これがDDDとの関連に近い点です。

しかし、こうして定義したユーザのPipeを新たなサービスとして別の利用者が使えるなら、それはサービスがプロセスで実現されている例にもなります。

ということで、鶏と卵の議論に近い話かもしれませんが、現在の流行り言葉(Mashup, SOA, DDD, BPM)の相互関係がPipesの例からも観察できると言えます。

MashupとSOAについて

“SOA and DDD”について

再度InfoQの記事についての感想です。

  1. SOA and DDD

SOAにおけるサービスと、少し前のコンポーネントベース開発(CBD)のコンポーネントを比較検討しており、サービスはビジネスよりの制約を持ったコンポーネント(ビジネスコンポーネント?)相当だとし、むしろSOAのサービスはDDDでり扱う概念(Ubiquitous Language)相当に近いのでは、と言っているようです。

元々SOAの議論には、サービスを一般的なサービスと捉える人からビジネスサービスに限定して捉える人まで、かなり幅広い捉え方があります。この記事はビジネスサービスに近づけたほうが良いと言う主張を紹介しています。DDDで取り扱う概念に近づけ、ビジネスサービスだと言うと、確かにそれはそれで一つの世界になりますが、閉じた世界になるかどうかが問題のように思います。

主題から少し離れますが、このようにするとビジネスサービスのプロセスとの関連が曖昧になってきそうです。ビジネスサービスを実現するのがビジネスプロセスなのか、ビジネスプロセスを実現するためにビジネスサービスが使われるのか、それともそのハイブリッド形態なのか、というような話です。また別の課題として、DDDの考え方に基づくと、どうしてもドメインエンティティ中心の比較的単純なUI設計になってしまい、ユーザから何でも出来る(複雑な)UIを要求されるとマッピングを取るのが大変かなという気がします。

元の記事の結論部分まで飛ぶと、結局皆の合意できる「これこそがSOAのサービスの定義」というものが無いことが問題とされています。余り面白くない結論です。タイトルにある「サービス指向アーキテクチャ」と「ドメイン駆動設計」は言葉としては別の世界を記述するもののように思えますが、この記事はそれらを合体させた「ドメイン駆動サービス指向アーキテクチャ設計」といったものを示唆しているようです。

“SOA and DDD”について

MSDNマガジン2月号について

過去にOsloやM言語について簡単に触れましたが、本家のMSDNマガジン2月号に関連記事が出ています。

  1. “Oslo” プラットフォームでメタデータ ベースのアプリケーションを構築する

更に、そのうち何か書こうと思っていたDDDの解説記事もあります。

  1. ドメイン駆動設計の概要

そして

  1. マイクロソフト アーキテクト S + S サミット

の資料も公開されています。こちらはクラウド(アーキテクチャ)系の話が中心です。

やはりMicrosoft Worldも豊富な開発者をかかえていて、将来に向かって先進的な分野でもcompetitiveな取り組みが続けられているようです。

MSDNマガジン2月号について