2012年3月26日月曜日

Domain-Driven Design (DDD)

3月19日(月)に要求開発アライアンスのセッション『Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標』を行いましたが、説明を端折ったところを中心にスライドの回顧をしています。

「Domain-Driven Design (DDD)」として用意した以下のスライドを説明します。



セッションの全体構成は以下のようになっています。

  • 関数型プログラミング
  • Object Functional Programming (OFP)
  • Object Functional Analysis and Design (OFAD)
  • 応用

この中で4番目「応用」は、今OOADやクラウド・プラットフォームで話題となっている技術がOFADでどのような影響を受けそうなのかということを考えてみる趣旨のセクションです。

具体的に考えてみることで、OFADへのイメージがより明確になるかなと思ったのですが、残念ながら時間の関係で省略することになってしまいました。「応用」は33枚目からなのですが、50分だと30枚ぐらいが目安ですね。

上記スライドは、その「応用」の一つとしてDomain-Driven Design (DDD)を取り上げたものです。DDDはいうまでもなく、エリック・エヴァンス氏の以下の書籍によるドメイン層の設計技法です。

OOADの中での位置付け

まず、OOADの中でのDDDの位置付けについて確認しておきましょう。以下は、当日は他のスライドと内容がかぶるので非表示にしていたスライドです。


この図ではOOADを、大きくクラス図を中心としたドメイン・モデリングとユースケース/協調を中心としたアプリケーション・モデリングの2つに分けています。

さらに、ドメイン・モデリングは、ドメイン・モデルそのものを作成する業務モデリング&要求モデリングとドメイン・モデルの実装方法をモデル化するシステム・モデリング&設計の2つに分けることができますが、DDDがカバーするのは後者システム・モデリング&設計の所です。

セッションのテーマであるOFADでは、"関数型の所は主にユースケース、協調に関するモデリング技術と関係を持ってくるのでDDDは直接影響を受けないだろう"、というのがこのスライドのDDDに関する部分の趣旨です。

このスライドを使っていた場合は、以下のようなことを口頭で補足する感じです。

まず、ドメイン・モデルという観点では関数型はルール・モデルに影響を与える可能性があります。とはいえ、ルール・モデルは関数型をさらに発展させた論理型と対応させるべきモデルなので、関数型の段階の影響はそれほどないのではないかと思います。

それより、関数型言語で実現するDSLでルール・モデルを記述するようなアプローチはありそうなので、その点は継続して動向を見ていく必要はありそうです。

[参考]業務モデリングと要求モデリング

ちなみに前者の業務モデリング&要求モデリングは、以下のような本が役に立ちます。

(翻訳は分かる範囲で載せていますが、翻訳品質は未チェックです。今回調べてみて分かったのですが、翻訳の方は良い本でもすぐに絶版になってしまいますね。早く電子出版に移行して欲しいです。)

DDDによる設計と関数型言語

OFADによってDDDの位置付けが変わったり、DDDによってOFAD側に影響が出るようなことはなさそうですが、DDDの設計・実装技法と関数型言語の関係はまた別です。

最初のスライドに戻ると、DDDのパターンの中でいくつか関数型的な手法が見られるので、それをピックアップしています。

まず、重要なのは:

  • Declarative Design - Domain Specific Language
  • A Declarative Style of Design - Composite Specification
  • Declarative Style

という形で宣言的な設計スタイルを推奨していることです。宣言的にすることでDSLを適用できたり、仕様の合成もできるようになるわけですね。関数型と相性がよい設計スタイルです。手続き型的な手法はこういったことができずに、どうしても手作業が多くなってしまいます。

OFAD的に翻案すると「いかに、手続き型な部分を減らして、関数型的な部分(DSLを併用)を広げていくのか」、というのが今後のソフトウェア設計の軸になるのではないかと思います。

直接関数型を意識しているのは以下の項目。

  • Side-Effect-Free Functions
  • Closure of Functions

Context Mapは、複数のドメイン・モデルを併用するときの技法です。最近だとLensのような代数的/圏論的な手法も登場してきているので、こういった手法を適用できる可能性があります。

Value Objectは、Entityの内容を持ちまわったり、協調の中で発生する揮発性の情報を持ちまわるためのオブジェクトで、DTO的な用途のオブジェクトを、モデリング上の一級市民に格上げしたものです。定義的にはID(がモデル上の意味)を持たないオブジェクト、オブジェクトの同一性の比較がIDではなくて、格納されている値の比較で行われるオブジェクトということです。

DDDでは、Value Objectとしていますが、基本的な値を表現するオブジェクトと、XML的な構造を持ったオブジェクトは分けたほうがよいと思うので、ボクは前者をValue、後者をDocumentと使い分けています。

Value Objectは、不変オブジェクトであることが推奨されており、関数型の代数的データ型や永続データ構造(関数型言語の技術マップ)といった技法で実現するのがぴったりはまります。(とはいえ、性能問題やプログラミングの手間もあるのでDDDには「Special Cases: When to Allow Mutability」というノートも書いてあります。実際問題として、Value Objectを完全に不変オブジェクトにするとプログラミングの手間が大変ですので、プログラマの習性としては分かっていても可変オブジェクトにしてしまいがちです。そこで、不変オブジェクトとこれをビルドするためのBuilderを自動生成しようというのが拙作のSimpleModelerのアプローチです。)

DDDは、筋のよいOO設計、OOP実装技法の経験則という側面が大きいと思いますが、DDDが出版された2003年当時OOP/OOAD全盛の中でも、関数型(的なアプローチ)の存在感はなかなか大きい感じがします。

関数型言語が実用化された今となっては、できるだけDSL&関数型的な手法で実現する範囲を大きくしていくことが、新しい経験則になっていくのではないかと思います。

具体的には、以下に書いたようなことですね。

諸元

当日使用したスライドは以下のものです。(PDF出力ツールの関係で、当日は非表示にしたスライドも表示されています)

このスライド作成の様子は以下の記事になります。

回顧は以下の記事になります。

投稿者 時刻:
ラベル: , ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)