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はいうまでもなく、エリック・エヴァンス氏の以下の書籍によるドメイン層の設計技法です。
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjt3-XD0kvBuA17SqrvJfAMe70JjCQDaLsDLHuEEfiZwRFv0Zyjg6-dtj8oY8X9fv0JGxfj6XbAaluyLqrg_kNewm0ApkqrUizyfMIKEPqXdv60O38rAxkigljHYfTPfi_JNvVsd1v7PTQ/s400/ddd.jpg)
セッションの全体構成は以下のようになっています。 ●関数型プログラミング ●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でルール・モデルを記述するようなアプローチはありそうなので、その点は継続して動向を見ていく必要はありそうです。
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEijsGcUdwW1KAfk8AROHGiXyYLWMLgLzWAs66sWTHGtTrwCVrGC8Rb9gxJor4NCFmK7-oNMy29Vd1FTQc45Zge8wU3aO74Hyl418PLz19RckvyGVH9mISaldSbmonDgr7k9KWVZvLaSDRA/s400/dddinooad.jpg)
この図ではOOADを、大きくクラス図を中心としたドメイン・モデリングとユースケース/協調を中心としたアプリケーション・モデリングの2つに分けています。 さらに、ドメイン・モデリングは、ドメイン・モデルそのものを作成する業務モデリング&要求モデリングとドメイン・モデルの実装方法をモデル化するシステム・モデリング&設計の2つに分けることができますが、DDDがカバーするのは後者システム・モデリング&設計の所です。 セッションのテーマであるOFADでは、"関数型の所は主にユースケース、協調に関するモデリング技術と関係を持ってくるのでDDDは直接影響を受けないだろう"、というのがこのスライドのDDDに関する部分の趣旨です。 このスライドを使っていた場合は、以下のようなことを口頭で補足する感じです。 まず、ドメイン・モデルという観点では関数型はルール・モデルに影響を与える可能性があります。とはいえ、ルール・モデルは関数型をさらに発展させた論理型と対応させるべきモデルなので、関数型の段階の影響はそれほどないのではないかと思います。 それより、関数型言語で実現するDSLでルール・モデルを記述するようなアプローチはありそうなので、その点は継続して動向を見ていく必要はありそうです。
0 件のコメント:
コメントを投稿