ドメイン駆動設計と業務分析の違い - 第28回 関西IT勉強宴会 -

ドメイン駆動設計(DDD)とはなにか？

それを知るには「ドメイン」という言葉の定義を知る必要があります。一般にドメインエキスパートが出てくる文脈でドメインというと業務ドメインを指しています。そして業務ドメインというと業務分析の対象になっています。

しかし、今回の関西IT勉強宴会 ドメイン駆動設計を知ろうの議論を通じて、 ドメイン駆動設計でいうドメインと業務分析でいうドメインが異なっている事がわかりました(参考： 2013-12-13（金）第28回関西IT勉強宴会　ドメイン駆動設計を知ろう（関西ＩＴ勉強宴会のブログです）、ドメイン駆動設計に出てくる「モデル」とは何ですか？（プログラマの思索）)。

業務分析の対象となるドメイン

議論中の言葉をお借りすると、DOAで行う業務分析では、管理レベルからドメインを見ます。ユースケースによってシステムの内側と外側の境界を定めて、その内部を開発します。

IBM-DOAで用いられるDFDでは、トップレベルのコンテキスト・ダイヤグラムでシステムの境界を定めて、トップダウンにプロセスを分割します。部分的に深められることや洗練される事はありますが、システムの境界は基本的に変わりません（最近はユースケース図になっているかもしれませんがが、境界を定める点は同じでしょう）。

ドメイン駆動設計の対象となるドメイン

これに対してドメイン駆動設計ではユーザとの界面は、システム側のUIでさえも対象としていません。ドメイン知識を持つドメインエキスパートと開発者との間でユビキタス言語を定め、モデル駆動で開発します。

この点がディスカッションでは話題になりました。システムの境界を定めるのではなく、SEA関西「ぐるぐるDDD/Scrum」 - モデルは実装のうずまきで洗練される - で経験したように、コアな業務からインクリメンタイル（漸増的）に開発していくイメージの様です。

ユビキタス言語とデータディクショナリとの違い

懇親会で講演者の後藤さんを交えてお話しさせていただけたので、 ユビキタス言語とデータディクショナリとの違いをおうかがいしました。データディクショナリは名詞しかありませんが、ユビキタス言語は名詞と動詞があることや、著者のエリック・エヴァンスは言葉を大切にしているとのお話をうかがいました。

このあたり、青木淳さんのSMALLTALKの黒本にあるように細胞をメタファとしてデータとメソッドでオブジェクトをカプセル化したオブジェクト指向の流れを感じます。

ドメイン駆動設計と業務分析の違い

業務分析を行う基幹業務では、一定のまとまりの機能が必要とされます。会社によって管理方法の違いがありますが、制約となる法律やルールは変わりません。そこで、一定の機能を含む境界が生まれます。

これに対してリーンスタートアップのように、最低限の機能によって大きな効果を得ようとする場合は、よりコンパクトな機能が求められます。ドメイン駆動設計のようにインクリメンタルに機能追加して、ビジネスに適したソフトウェアを実現することが求められていると思います。

(おまけ)プロセス再考

この関係はフレームワークとしてプロセスがパッケージングされているスクラムと、ムダの少ないプロセスを構築していくリーン開発の関係と似ています。

開発チームを一定の水準まで実現する場合や、流動化した労働力による混合チームを実現する際にはスクラムが向いています。完全型チケット駆動開発の目指すところも同じです。

一方、すでに開発チームが存在し、原則やカンバンを導入するなど、徐々に改善したい場合はリーン開発が向いています。補完型チケット駆動開発も同じような使い方になります。

まとめ

開発にしろプロセスにしろ、必要な特性に応じた方法を用いる事が大切です。それにはブームだからという理由ではなく、説明責任が果たせるだけの理解が必要でしょう。

今回の勉強会に参加して、議論の中でDOAとオブジェクト指向は目指す方向性が違う事がわかりました。単に講演を聴くだけでなく、議論する事が大切だと思いました。

みなさま、ありがとうございました。