frameworks we live by: design by day-to-day framework development: multi-paradigm design in practice

PHP Conference JAPAN 2015October 3 2015

Frameworks We Live ByDesign by day-to-day framework development:

Multi-paradigm design in practice

PHP MentorsKUBO Atsuhiro @iteman

https://twitter.com/iteman

Copyright (c) 2015 KUBO Atsuhiro <[email protected]>, All rights reserved.

Frameworks We Live By

1.ドメインモデルの設計マルチパラダイムデザインによるドメイン駆動設計の実践● 共通性と可変性● 問題ドメインと解決ドメイン● ドメインモデルの設計

解決ドメインの抽象による問題ドメインの再定義

2.フレームワーク開発による設計


久保敦啓 (KUBO Atsuhiro)● Programmer, Mentor at @phpmentors,

@piece_framework Project Lead/Developer, Business Owner.

● A framework multi-paradigm guy

https://twitter.com/phpmentors

https://twitter.com/piece_framework


これまでに作ったフレームワーク● 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


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


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

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

概念メタファー

https://ja.wikipedia.org/wiki/%E3%82%B8%E3%83%A7%E3%83%BC%E3%82%B8%E3%83%BB%E3%83%AC%E3%82%A4%E3%82%B3%E3%83%95


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


サブドメイン● 問題ドメインの類似サブシステム群の共通性と可変性を表現する

抽象– ドメインそのもの

● よく知られたサブドメインは設計の優れたスタートポイント● アーキテクチャ＝ドメインモデルの再利用単位

– サブドメインのフレームワーク● ドメインの階層化

– サブドメインはそのドメインの語彙が現れなくなるまで繰り返し分割され階層化される。

例：ワークフロードメインをどれだけ細分化してもステートマシンドメインは現れない。


Workflowerによる例：ワークフロードメインのサブドメイン分割

● ワークフロー（Workflow）● プロセス（Process）● 定義（Definition）● 永続化（Persistence）


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


共通性・可変性分析● 演繹的共通性と帰納的共通性● 共通性次元

データ構造、名前と振る舞い（識別子、シグネチャ、型）、アルゴリズム● 共通性カテゴリ

– 共通性次元によってグループ化されるカテゴリ。ドメインの可変パラメーターとなる。

● 空間的可変性と時間的可変性– 変更されたアプリケーションはフレームワークの新たなインスタンスである。

● 機構と方針の分離（Separation of mechanism and policy）– 機構は安定、方針は不安定– インスタンスから見ると共通性は機構としてフレームワークに埋め込まれ、可変

性は方針としてインスタンス毎の定義の対象となる。


問題ドメイン分析● アプリケーションではなくそのファミリの分析

– 共通性次元によって共通性をグルーピングしたもの– ドメインを形成– 可変パラメーターで可変性を表現

● ドメイン分析のメリット– 再利用をサポートする一般性– 柔軟性＝変更からの復元力（resilience）

● グローバルに抽象化、ローカルに具象化– 例：BPMN 2.0を限定的にサポートするワークフローエンジン

● 問題ドメイン分析＝ドメイン駆動設計● 可変性テーブル、可変性依存図として形式化


Workflowerによる例：ワークフロードメインの可変性依存図


Workflowerによる例：ワークフローサブドメインを分析する

OMGのBPMN 2.0ドキュメントを参考に第1段階のアーキテクチャーを設計…

Workflow: ConnectingObject: - SequenceFlow FlowObject: Activity: - Task Event: - StartEvent - EndEvent Gateway: - ExclusiveGateway


解決ドメイン分析● 問題ドメインの共通性・可変性に対応する解決

ドメインの抽象を分析する。● 従来から設計者の暗黙知として存在● ファミリテーブルとして形式化（再利用可能）


ドメインモデルの設計● 設計＝変換分析（transformational analysis）

– 問題ドメインの構造と解決ドメインの構造のマッピング

● 解決ドメインの抽象で問題ドメインの構造を再定義、洗練（第2段階のアーキテクチャの作成）

● DDDのモデル駆動設計が目指す単一のモデルを実現


ドメインモデルの設計

解決ドメインの構造が問題ドメインの構造を変化させる。

分析、設計の繰り返しが必要となる根拠となる。

例：

元の問題: 「これまで考えられてきた設計やプログラミングの便法を可能なかぎり利用して、複雑な関数の導関数を計算する。」

変更された問題: 「自動微分を使用して、複合関数の導関数を計算する」― マルチパラダイムデザイン p.207


Workflowerによる例：ドメインモデルを設計する

● 型の共通性から組織化…


Workflowerによる例：ドメインモデルを設計する

操作（振る舞い）の共通性から組織化…


1.問題ドメインをサブドメインに分割する。

2.サブドメインの共通性・可変性を分析する。

3.解決ドメインの共通性・可変性を分析する。

4.解決ドメインの抽象を使ってドメインモデルを設計する。

5.ドメイン特化言語を評価、設計する。


ドメイン特化言語● Domain-Specific Language: DSL● 問題ドメインのインスタンスを定義するカスタ

ム言語。ドメインの可変性を表現する。● 問題ドメインの共通性・可変性が既存のソ

リューションドメインの抽象に適合しない場合に有用

● 1つの解決ドメインとなる。


Workflowerによる例：DSLを評価、設計する

● ワークフロー定義はソースコードによる記述が困難…

● ワークフロー定義はOMGが定義するBPMN 2.0（XML）がデファクトスタンダード– OMG提供のXMLスキーマファイルでバリデーショ

ンが可能– 多数存在するBPMN 2.0対応のグラフィカルエディ

ターを利用可能


Workflowerによる例：DSLを評価、設計する

BPMN2 Modeler（Eclipseプラグイン）のエディター


Frameworks We Live ByDesign by day-to-day framework development

フレームワーク● ソースコードとランタイムのオブジェクトによって

サブドメインの構造（アーキテクチャ＝ドメインモデル）を表現するソフトウェアパッケージ例：

● Webアプリケーションフレームワーク● ORMフレームワーク● ワークフローエンジン

● アーキテクチャ＝ドメインモデルの再利用単位● 問題ドメインからは1つのサブドメインとして利用

フレームワーク開発：MPDの実践● 目の前にあるニーズから問題にアプローチするだけ（ア

プリケーション分析）では、広い領域に適用できるような共通性を見つける機会が制限される。

● あるアプリケーションを作る際に、そのアプリケーションをフレームワークとその最初のクライアントという構成に意図的に持ち込むことで、共通性を見つける機会の制約を打ち破り、広い領域に適用できるソリューションを作り出そうということである。

● フレームワークの作成では必然的にアプリケーションではなくドメインに対して設計を行うことになる。


Coding We Live ByDesign by day-to-day coding


コーディング：MPDの実践● 設計と実装、その活動の統合を目指して

– 設計してからの実装ではなく実装を通した設計を指向する。● 開発環境・技術の進化により現実のものとなっている。

– 開発環境による高速なフィードバックがそれを可能にしている。● 現在の実装（コーディング）は当時のCoplien氏の見通し以上

の活動になっている。

それゆえ：

プログラマーは設計者である。実装の中心的な関心を設計と位置づけ、意図を持った設計（intentional design）を作り出すこと。


Coding We Live By

1.ドメインモデルの設計マルチパラダイムデザインによるドメイン駆動設計の実践● 共通性と可変性● 問題ドメインと解決ドメイン● ドメインモデルの設計

解決ドメインの抽象による問題ドメインの再定義


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

https://en.wikipedia.org/wiki/George_Lakoff

https://ja.wikipedia.org/wiki/%E3%82%B8%E3%83%A7%E3%83%BC%E3%82%B8%E3%83%BB%E3%83%AC%E3%82%A4%E3%82%B3%E3%83%95

http://ja.wikipedia.org/wiki/%E8%AA%8D%E7%9F%A5%E8%A8%80%E8%AA%9E%E5%AD%A6

frameworks we live by: design by day-to-day framework development: multi-paradigm design in practice

Software