[#benkyoenkai] DDD（ドメイン駆動設計）と道具と他流試合

「すっきりしました。今まで学んできた事が一つになりました！」と言ったのは、今や同僚のSさん。分厚い見た目に負けて読めなかったDDD本を読んでみたいと言われたのでお貸しして、感想を聞きました（いわゆる手抜き）。

言ってる事は理解できたのですが、これまでいくつものDDDの講演を聞いた中でそのようなイメージを抱く事がなかったので、「そんな感想もあるんですね」と思っていました。

今回、IT勉強宴会で杉本さんの講演を聞いて、ようやくイメージがわきました。

共に開発するDDD

杉本さんによれば、“ドメイン駆動設計(※)とは、オブジェクト指向ベースの知識体系を受け入れつつも、エンジニアの関心を、プログラムのテクニカルな構造に留まらず情報処理モデルそれ自体の構築に向けようとする試みである（私見）”とのこと。「これだ！」と思いました。

ドメイン駆動設計の実践例 - 経営管理基盤 fusion_place - from 啓 杉本

アジャイル開発には、似ている言葉がたくさんありました。

• オンサイト顧客、全員同席（XP：アジャイル開発の生産性の高さを考える）
• 同じ方向を向く（請負契約との対比から：アジャイル開発の「考え方」と「やり方」を学べ）
• コタツモデル、HOWの突き上げ（要求開発：要求開発はアジャイルのフロントローディング）

これらはソフトウェア開発に必要なある一面を示していましたが、なにかゴールそのものでない、少しモヤモヤしたものを感じていました。

今回の杉本さんのお話で、我々が開発しているのはお客様の情報処理モデルそれ自体であると再認識しました。そのための道具が、ユビキタス言語であり、ドメインのパターン、DSL、ドメイン特化基盤（DSP）なのでしょう。

道具と思考

杉本さんがDDDはドメインの解決領域を対象にするとされたのに対して、2番目の佐野さんの発表では解決領域の手法やツールが問題領域に制限を与えるとのお話でした。

たとえば「指定されたファイルをソートする」という課題が与えられたとき、その解決法に依って、引数のファイル名をオープンして、stdinで、sortコマンドで、エクセルで、と課題の置かれた状況が変質していきます（注：言い換えてます）。

たしかにそうなのですが、DDDにおけるユビキタス言語は、概念を整理してより前向きに開発を進めるためのものではないかと思いました。

杉本さんが紹介されたfusion_placeにも問題のあり方を決めてしまう側面があります。しかしDSPとして考えると、ドメインの基本的な解決パターンを提供する事でその詳細に対する考慮を不要にして、より大切なことに力を割く事ができます。

これは、Rubyのまつもとさんが言われた「ある種の制約は自由を増やす」の一例ではないかと思いました。

ドメインを極めたあと

最後の渡辺さんの講演では、ドメインには階層性があって抽象度の高いドメインによってより具体的なサブドメインの実現を容易にする。まずは、興味があって、今後も期待できるドメインを決めて、極めなさいとのこと。

何か得意なプログラミング言語があれば、それが自分の強みになります。それを基に仕事をしていく事がエンジニアの道なのでしょう。

でも渡辺さんがスゴいのは、販売管理のドメインに詳しいだけではなく、他の業務にも詳しくて、その上位の抽象度の高いドメインを極められているからだと思いました。

まずはドメインを決めて、その後に幅を広げる事が大事だと思いました。

おわりに

業務系のお話が多いIT勉強宴会に何度も参加させていただいていますが、実はあまり関係のない開発をしています。いわば他流試合です。

他分野の情報はとても刺激的で、今までの知識を見直すきっかけになっています。そういった刺激をいつも受ける事ができて、とても感謝しています。

今回のDDDに関しても業務の目を通した意見をうかがう事で、業務ドメインを考える際に技術者の知識やパターンが活かされていて、ツールや手法という形で制約や自由を与えられている事を理解する事ができました。ありがとうございました。