Frameworks We Live By: Design by day-to-day framework development: Multi-paradigm design in practice

PHP Conference JAPAN 2015
October 3 2015
Frameworks We Live By
Design by day-to-day framework development:
Multi-paradigm design in practice
PHP Mentors
KUBO Atsuhiro @iteman

Copyright (c) 2015 KUBO Atsuhiro <kubo@iteman.jp>, All rights reserved.
1.ドメインモデルの設計
マルチパラダイムデザインによるドメイン駆動設計の実践
●
共通性と可変性
●
問題ドメインと解決ドメイン
●
ドメインモデルの設計
解決ドメインの抽象による問題ドメインの再定義
2.フレームワーク開発による設計

久保敦啓 (KUBO Atsuhiro)
●
Programmer, Mentor at @phpmentors,
@piece_framework Project Lead/Developer,
Business Owner.
●
A framework multi-paradigm guy

これまでに作ったフレームワーク
●
Net_UserAgent_Mobile（2003）
HTTP mobile user agent string parser
●
Piece_Unity（2006）
A Web application framework
●
Domain Kata（2014）
Kata for domain models
●
Workflower（2015）
A BPMN 2.0 compliant workflow engine for PHP

〜マルチパラダイムデザインによるドメイン駆動設計の実践〜

優れた設計というものは、どのよう
な場合であろうと、審美眼、洞察、
経験に依存するのである。
― マルチパラダイムデザイン p.215

Domain-Driven Design: DDD
(Evans 2003)

DDDのアクティビティ

DDDの問題点
●
モデル駆動設計は問題ドメインの概念に根ざした
分析、設計、実装における単一のモデルの開発を
目指すものだが、その実現方法が不明確である。
●
分析（モデリング）手法についての具体的な記述
がアナリシスパターンを適用する、責務のレイヤ
を除いて見つけられない。
●
ドメイン工学に関する記述がなく、ドメイン特化
言語についても不十分な記述に留まる。

Multi-Paradigm Design: MPD
(Coplien 1998)

MPDのアクティビティ
1.問題ドメインをサブドメインに分割する。
2.サブドメインの共通性・可変性を分析する。
3.解決ドメインの共通性・可変性を分析する。
4.解決ドメインの抽象を使ってドメインモデルを
設計する。

マルチパラダイムデザイン
●
James O. "Jim" Coplien氏が提唱するドメイン工学の設計手法
– アプリケーションを再利用可能な問題ドメインのアーキテクチャとそのインス
タンスという構図で認識し、そのリファレンスアーキテクチャの作成に主眼を
置く。ジェネレーティブプログラミングとオーバーラップする。
●
人間の認知モデルに基づく共通性と可変性という観点から問題ドメイ
ンを分析
●
ドメインとドメイン間の関係からなる構造（アーキテクチャ＝ドメイ
ンモデル）として問題ドメインを組織化（第1段階のアーキテクチャ）
●
解決ドメインによって支援される抽象を使って問題ドメインの構造を
表現＝設計（第2段階のアーキテクチャ）
解決ドメインの抽象を意図的に問題ドメインに組み込む！

マルチパラダイムデザイン
●
“MPD is predicated on analysis, and is rooted
in a model of commonality that concretely
guides choices”
― https://twitter.com/jcoplien/status/645654740911681536

MPDの重要性
●
設計者がモデルを設計することが中心的なアクティビティと
して明示的に位置づけられている。
●
人間の認知モデルに基づく共通性と可変性による設計原理ゆ
え高い普遍性を持つ。
●
現実にある多くの優れたフレームワークにその使用が認めら
れる。すなわち現実を説明できる力を持つ。
例：
●
Symfony（PHP）
●
Ruby on Rails（Ruby）
●
Spring Framework（Java）
●
Boost（C++）

パラダイム
●
世界に関するモデル
●
計算完全性モデル
●
共通性と可変性の配置に関するモデル
＝マルチパラダイムデザイン

MPDのゴール
●
システムの構築方法をドメインの構造（アーキテ
クチャ＝ドメインモデル）自身が示すようにする
こと
●
意図性（intentionality）
●
システムレベルにおけるソフトウェアの理解
●
進化の容易さの拡大
のサポートによって実現
●
ニーズを柔軟性に富む弾力ある構造（アーキテク
チャ＝ドメインモデル）に変換すること

MPDとは何か？
●
共通性と可変性による設計パラダイム
– 人間の認知モデルに基づく共通性と可変性という観点から問題ドメ
インを分析する抽象モデル
– 共通性と可変性を管理する様式（style）という単一の観点から解決
ドメイン（パラダイム）をまとめる統一設計理論
●
設計者の経験と直観やドメインの歴史的意味を頼りに、共通
性と可変性によって問題ドメインが持つ本質的な構造を明ら
かにし、それに適合する解決ドメイン（パラダイム）を選択
可能にする。
●
分析（ドメイン知識の獲得）ではなく設計（ドメイン知識の
組織化）を指向する。

MPDの認知モデル
●
認知言語学に基づくモデル
●
概念メタファーを提唱するGeorge P. LakofとMark
Johnsonらによって切り開かれた新たな認知モデル
●
古典的なカテゴリー観だけでなく新しいカテゴリー理論
に基づく抽象のモデル
– 古典的なカテゴリー観：全成員に共通する属性によってカテゴ
リーを規定
– 新しいカテゴリー理論：プロトタイプ理論、基本レベルカテゴ
リー
●
負の可変性

“われわれが普段、ものを考えたり行動したり
する際に基づいている概念体系の本質は、根本
的にメタファーによって成り立っているのであ
る。”
― レトリックと人生 p.3
概念メタファー

●
認知言語学の用語で「ある概念領域を別の概念領域を用
いて理解する事」
– 概念メタファー（conceptual metaphor）
●
構造のメタファー（structural metaphors）
●
方向づけのメタファー（orientational metaphors）
●
存在のメタファー（ontological metaphors）
– メトニミー（metonymy）
– シネクドキー（synecdoche）
●
“人間の概念体系がメタファーによって構造を与えら
れ、規定されている” ― レトリックと人生 p.7

●
存在のメタファーの例：
THE MIND IS AN ENTITY
＜知力（精神）はひとつの存在物である＞
●
THE MIND IS A MACHINE
＜知力は機械である＞
– My mind just isn't operating today.
＜私の頭は今日は全然作動して（＝働いて）いない。＞
― レトリックと人生 pp.41-42

“レイコフはここから発展して、人間の抽象的
な概念能力は、経験に基づいた具体的・身体的
な認知機構からのメタファー的拡張によって可
能になっていると主張し、心身二元論に基づい
た西洋哲学の伝統に対する批判を行ってい
る。”
― ジョージ・レイコフ - Wikipedia

問題ドメイン
●
システムやソフトウェアの当面の関心のある領
域。
例：会計、販売管理、生産管理、ソースコード管
理、Webアプリケーション、オブジェクトリレー
ショナルマッピング、バリデーション、ワークフ
ロー

サブドメイン
●
問題ドメインの類似サブシステム群の共通性と可変性を表現する
抽象
– ドメインそのもの
●
よく知られたサブドメインは設計の優れたスタートポイント
●
アーキテクチャ＝ドメインモデルの再利用単位
– サブドメインのフレームワーク
●
ドメインの階層化
– サブドメインはそのドメインの語彙が現れなくなるまで繰り返し分割さ
れ階層化される。
例：ワークフロードメインをどれだけ細分化してもステートマシンドメ
インは現れない。

Workflowerによる例：
ワークフロードメインのサブドメイン分割
●
ワークフロー（Workflow）
●
プロセス（Process）
●
定義（Definition）
●
永続化（Persistence）

解決ドメイン
●
問題ドメインを解決するための抽象基盤となる
技術領域。
例：プログラミング言語、フレームワーク、ライブ
ラリ、デザインパターン、オブジェクト指向プログ
ラミング、ルールベースプログラミング、関数プロ
グラミング、リレーショナルモデル

共通性・可変性分析
●
演繹的共通性と帰納的共通性
●
共通性次元
データ構造、名前と振る舞い（識別子、シグネチャ、型）、アルゴリズム
●
共通性カテゴリ
– 共通性次元によってグループ化されるカテゴリ。ドメインの可変パラメーターと
なる。
●
空間的可変性と時間的可変性
– 変更されたアプリケーションはフレームワークの新たなインスタンスである。
●
機構と方針の分離（Separation of mechanism and policy）
– 機構は安定、方針は不安定
– インスタンスから見ると共通性は機構としてフレームワークに埋め込まれ、可変
性は方針としてインスタンス毎の定義の対象となる。

問題ドメイン分析
●
アプリケーションではなくそのファミリの分析
– 共通性次元によって共通性をグルーピングしたもの
– ドメインを形成
– 可変パラメーターで可変性を表現
●
ドメイン分析のメリット
– 再利用をサポートする一般性
– 柔軟性＝変更からの復元力（resilience）
●
グローバルに抽象化、ローカルに具象化
– 例：BPMN 2.0を限定的にサポートするワークフローエンジン
●
問題ドメイン分析＝ドメイン駆動設計
●
可変性テーブル、可変性依存図として形式化

ワークフロードメインの可変性依存図

ワークフローサブドメインを分析する
OMGのBPMN 2.0ドキュメントを参考に第1段
階のアーキテクチャーを設計…
Workflow:
ConnectingObject:
- SequenceFlow
FlowObject:
Activity:
- Task
Event:
- StartEvent
- EndEvent
Gateway:
- ExclusiveGateway

解決ドメイン分析
●
問題ドメインの共通性・可変性に対応する解決
ドメインの抽象を分析する。
●
従来から設計者の暗黙知として存在
●
ファミリテーブルとして形式化（再利用可能）

●
設計＝変換分析（transformational analysis）
– 問題ドメインの構造と解決ドメインの構造のマッピ
ング
●
解決ドメインの抽象で問題ドメインの構造を再
定義、洗練（第2段階のアーキテクチャの作
成）
●
DDDのモデル駆動設計が目指す単一のモデルを
実現

解決ドメインの構造が問題ドメインの構造を変化させ
る。
分析、設計の繰り返しが必要となる根拠となる。
例：
元の問題: 「これまで考えられてきた設計やプログラミング
の便法を可能なかぎり利用して、複雑な関数の導関数を計
算する。」
変更された問題: 「自動微分を使用して、複合関数の導関数
を計算する」
― マルチパラダイムデザイン p.207

ドメインモデルを設計する
●
型の共通性から組織化…

ドメインモデルを設計する
操作（振る舞い）の共通性から組織化…

1.問題ドメインをサブドメインに分割する。
2.サブドメインの共通性・可変性を分析する。
3.解決ドメインの共通性・可変性を分析する。
4.解決ドメインの抽象を使ってドメインモデルを
設計する。
5.ドメイン特化言語を評価、設計する。

ドメイン特化言語
●
Domain-Specific Language: DSL
●
問題ドメインのインスタンスを定義するカスタ
ム言語。ドメインの可変性を表現する。
●
問題ドメインの共通性・可変性が既存のソ
リューションドメインの抽象に適合しない場合
に有用
●
1つの解決ドメインとなる。

DSLを評価、設計する
●
ワークフロー定義はソースコードによる記述が
困難…
●
ワークフロー定義はOMGが定義するBPMN
2.0（XML）がデファクトスタンダード
– OMG提供のXMLスキーマファイルでバリデーショ
ンが可能
– 多数存在するBPMN 2.0対応のグラフィカルエディ
ターを利用可能

DSLを評価、設計する
BPMN2 Modeler（Eclipseプラグイン）のエディター

Design by day-to-day framework development

フレームワーク
●
ソースコードとランタイムのオブジェクトによって
サブドメインの構造（アーキテクチャ＝ドメインモ
デル）を表現するソフトウェアパッケージ
例：
●
Webアプリケーションフレームワーク
●
ORMフレームワーク
●
ワークフローエンジン
●
アーキテクチャ＝ドメインモデルの再利用単位
●
問題ドメインからは1つのサブドメインとして利用

フレームワーク開発：MPDの実践
●
目の前にあるニーズから問題にアプローチするだけ（ア
プリケーション分析）では、広い領域に適用できるよう
な共通性を見つける機会が制限される。
●
あるアプリケーションを作る際に、そのアプリケーショ
ンをフレームワークとその最初のクライアントという構
成に意図的に持ち込むことで、共通性を見つける機会の
制約を打ち破り、広い領域に適用できるソリューション
を作り出そうということである。
●
フレームワークの作成では必然的にアプリケーションで
はなくドメインに対して設計を行うことになる。

Coding We Live By
Design by day-to-day coding

コーディング：MPDの実践
●
設計と実装、その活動の統合を目指して
– 設計してからの実装ではなく実装を通した設計を指向する。
●
開発環境・技術の進化により現実のものとなっている。
– 開発環境による高速なフィードバックがそれを可能にしている。
●
現在の実装（コーディング）は当時のCoplien氏の見通し以上
の活動になっている。
それゆえ：
プログラマーは設計者である。実装の中心的な関心を設計と
位置づけ、意図を持った設計（intentional design）を作り出
すこと。

Coding We Live By
マルチパラダイムデザインによるドメイン駆動設計の実践
●
共通性と可変性
●
問題ドメインと解決ドメイン
●
解決ドメインの抽象による問題ドメインの再定義
3.コーディングによる設計

Code the Domain!
You are a Domain Coder!

参考文献
●
(Coplien 1998) Coplien, James O. Multi-Paradigm Design for C++ Reading, MA: Addision-
Wesley, 1998. 『マルチパラダイムデザイン』（金沢典子／羽生田栄一／平鍋健児訳、ピアソン
エデュケーション、2001、ISBN4894712989）
●
(Lakof and Johnson 1980) Lakof, George and Johnson, Mark Metaphors We Live By,
Chicago: University of Chicago Press, 1980. 『レトリックと人生』（渡部昇一／楠瀬淳三／下
谷和幸訳、大修館書店、1986、ISBN4469211257）
●
George Lakof - Wikipedia, the free encyclopedia
●
ジョージ・レイコフ – Wikipedia
●
認知言語学 - Wikipedia

Frameworks We Live By: Design by day-to-day framework development: Multi-paradigm design in practice

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Frameworks We Live By: Design by day-to-day framework development: Multi-paradigm design in practice

Ähnlich wie Frameworks We Live By: Design by day-to-day framework development: Multi-paradigm design in practice (20)

Mehr von Atsuhiro Kubo

Mehr von Atsuhiro Kubo (15)

Frameworks We Live By: Design by day-to-day framework development: Multi-paradigm design in practice