DDD

http://www.infoq.com/articles/ddd-in-practice
一通り読んだ．キー要素の登場が半端じゃないw．壮大だ．野球のオールスターゲームみたい．その内DSLのみをピックアップして思うところをテキトウに吐く．

ユビキタス言語を実現する方法の一つとして、ビジネスルールの一部を、ドメインエキスパートにもディベロッパにもコンピュータにもわかるDSLで記述する時代は、そんなに遠くないはず．

ワークフローのDSLは、悩ましい．ユーザの積極参加の開発（実行可能なワークフローは、ディベロッパ主体ではなく、ユーザ主体に書く）を考えれば、（DSLアプローチよりも）視覚的なモデリングツールからのコードジェネレーションアプローチは強力なコンセプト．

ワークフロー開発が、ディベロッパ主体でユーザとの共通理解を獲得したいだけなら、使い慣れたテキストエディタの生産性、、テキストインタフェースを使った他ツールと連携(grep,sed,diff,patch,Rubyでパースしてほにゃらら,構成管理ツール)、などなどを考慮すると、ワークフローをDSL記述した後に、ビジュアルモデルジェネレーションした方が有利か（上も下もへったくれもないので、俺は逆リバースとは呼ばないぞw）．

DSL記述で、ふつうの人がワークフローが簡単にわかる/書けるまで、テキストの構文をデザインできるなら、こしたことないが、テキスト記述の制約が強過ぎて、表現は難しいのかなと．

ワークフローは、「DSLのテキスト表記とビジュアルツールの図表記、どちらを【Common Language】とするか？」を議論するほかに、「ドメインエキスパート-ディベロッパ間で、ワークフローの【Common Experience】【Common Sense】をいかにして得て、ROIの高い(業務/ソフトウェア)デザインを導くか」の視点も欠かせない．例えば、現地のドメイン観察によるディベロッパの業務への積極参加とか(ソフトウェアとは異なる、プロダクトデザインの世界では,ポピュラー手法らしい。)、まじか！と組み合わせたロールプレイング法とか

おっと、何かのってきたw。が、収集がつかなくなってきたので、ストップ．