石橋秀仁(zerobase)書き散らす

まじめなブログは別にあります→ja.ishibashihideto.net

DCIアーキテクチャへの違和感から見えてくるユースケースDSL

DCIとDDD

DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticismを読んだり、DCI meetup w/ @jcoplien for Rubyistsに参加したりして、DCIアーキテクチャについて考えてきた。

DCIはメッセージパッシング指向だ。そのSmalltalk的なオブジェクト指向の原理はいいけど、実装が嫌だ。

そもそも、DCIアーキテクチャ提唱の目的は、メンタルモデルのセマンティクス・ギャップを埋めることだ。DDDの「ユビキタス言語」も、メンタルモデルのセマンティクス・ギャップを埋めるための要素であり手法だ。だから、ふつうにDDD(ドメイン駆動設計)をやればいいと思った。

DCIへの疑問

DCIでは、「オブジェクトのアイデンティティ」にこだわりすぎていることで、アーキテクチャが複雑になっている。

Decorator パターンは、既存のクラスを拡張する際にクラスの継承の代替手段として用いられる。継承がコンパイル時に機能を拡張するのに対し、Decorator パターンはプログラムの実行時に機能追加をする点が異なる。(Decoratorパターン - Wikipedia

例のmeetupでは「Decorator パターンを使うと、エンティティ・オブジェクトのアイデンティティに意味がなくなるから、ダメだ」といった話だった。

Decoratorではダメだから、動的にRole(役割)を着脱するためにはtraitという言語仕様が必要になる、という話だった。Rubyのmoduleでは着「脱」できないからダメだとか。

しかし、「Decorator によりアイデンティティの意味論が壊れる」(?)という点にこだわることには、どれほどの意味があるんだろうか。そこが疑問だ。

しかも、DCIアーキテクチャは「貧血症のドメイン・オブジェクト」というDDDアンチ・パターンにもなっている。

オブジェクトのアイデンティティにこだわることで、オブジェクトがドメインの知識を表現しない「単なるデータ」に成り下がっている。

これは間違いのないことで、DCIの意図そのものだ。それこそ、DCIのDが、DataのDである理由だろう。

こうしてオブジェクトからはぎ取ったドメイン知識は、ロール(言語によりtraitなどで実装される)に移される。これで銀行口座間の送金手続きをきれいに書けました、と。これがDCIの構想だ。

DCIをトップレベルアーキテクチャにするのが問題

DCIアーキテクチャMVCアーキテクチャを補完するものとして提案されている。つまりDCIアーキテクチャは、システムワイドのトップレベルアーキテクチャだ。

ぼくの考えでは、システムワイドなトップレベルアーキテクチャとしてDCIを採用することに問題がある。

なぜならば、DDDを推進すれば、「マイクロDCIアーキテクチャ」と呼ぶべき構造がシステムに無数に現れるはずだ。ならば、それでいいじゃないか。

「マイクロDCI構造」は次のようになっているはずだ。もちろん「DCI」とピタリ一致するわけではないが:

  • Data → エンティティ+値オブジェクト ※「存在」の表現
  • Context → 仕様+サービス ※「前提」「文脈」の表現
  • Interaction →サービス+アプリケーション ※「使用」「ユースケース」の表現

DCI提唱者の不満は、Interactionつまり「ユースケース」がドメインモデルとして表現されていないことだ。だから、それをどうにか表現する方法を考えればいい。

私見では、それはユースケースを記述するためのDSLだと考えている。jMockのような振る舞いを定義する宣言的なDSLによってユースケースを記述すればよいのではないか。

ユースケースDSLは、抽象度の高い(蒸留された)ドメイン言語として記述される。まずは深いリファクタリングを繰り返して現れてくる内部DSLとして実装されることになるはずだ。

ユースケースDSLは「手続き」そのものを記述するわけだから、「手続き」の要件を技術するjMock的なDSLとは若干違うものになるのかもしれない。

まだまだ難しい問題が控えているようだ。

関連情報

実践プログラミングDSL ドメイン特化言語の設計と実装のノウハウ (Programmer’s SELECTION)

実践プログラミングDSL ドメイン特化言語の設計と実装のノウハウ (Programmer’s SELECTION)