PHP Mentors

プログラミング道場生 kumamidori です。

5月31日に、Nagoya.php vol.5 に参加しました。

vol.5 のテーマは、「PHPフレームワークの１つであるBEAR.Sundayを触ってみよう」でした。 参加者全員で、BEAR.SundayワークショップWiki（チュートリアル）の内容に取り組みました。 私が見つけられた範囲だと、@kenji_sさん、@qckanemoto さんがブログにまとめられていますので、そちらをご覧頂ければと思います。記事の文末にそのリンクを貼ります。

BEAR.Sundayチュートリアル・スクリーンキャスト

この記事では、スクリーンキャストで、BEAR.Sundayチュートリアルのデモを、初心者なりの解説をまじえつつ紹介します。（見る人、誰もいないかもしれませんけれど・・・。）

• スクリーンキャストNo.１：フレームワークの概要とインストール（youtubeページへのリンクです）
• スクリーンキャストNo.２：リソースの作成、確認（youtubeページへのリンクです）

※今回動画を掲載することについて、フレームワーク作者に事前に許可を頂いております。

PHPカンファレンス関西について

BEAR.Sundayの作者である郡山さんは、6月28日(土)に開催されるPHPカンファレンス関西2014の基調講演をされる予定です。関西方面でご興味のある方は、懇親会の方にも申し込みされると良いかと思います。@hidenorigotoさんも遠方から来訪、参加されるそうです。

参考リンク

BEAR.Sundayに関するリンク

• BEAR.Sunday
• 郡山さんによるRESTful Meetup vol.3におけるLT資料： HTTP IS ONE THING
• PHPNW 2013(2) - Presentation « BEAR Blog

スクリーンキャスト内で引用した書籍

PHPメンターズブログにおける関連記事

• PHPメンターズ -> WEB+DB PRESS PHP連載第5回「BEAR.SundayでRESTfulなシステム開発」を執筆しました
• 道場生ブログ -> BEAR.Sunday meetup #3 in Osaka 参加レポート

Nagoya.php vol.5 に関するリンク

• Nagoya.php のFacebook
• Nagoya.php vol.5 BEAR.Sunday workshopに参加しました — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or something
• Nagoya.php vol.5 で BEAR.Sunday のワークショップを行いました | QUARTET Engineers’ Blog

※6月29日追記：

名古屋の方から、「写真、撮っていましたよね？」とリマインドを頂いたので、貼っておきます。

notice プログラミング言語Goの話ではありません。

技術評論社WEB+DB PRESSのPHP連載「巨人の肩からPHP - 先人たちに学ぶモダンプログラミング」の連載第8回「Go!ではじめるAOP 横断的関心事の分離とその実装」を収録したvol.76が発売されました。

• WEB+DB PRESS Vol.76｜gihyo.jp … 技術評論社

第8回では、AOPの用語や特徴などの解説と、Go!というAOPライブラリを使ってアスペクトを自作して適用するサンプルの解説を行っています。小さなコードでアスペクトの作成とポイントカットの指定等行っているので、実際に書いて動かしてAOPを理解したい方におすすめです。

• Go! Aspect-Oriented Framework

技術評論社WEB+DB PRESSのPHP連載「巨人の肩からPHP - 先人たちに学ぶモダンプログラミング」の連載第5回「BEAR.SundayでRESTfulなシステム開発」を収録したvol.73が発売されました。

• WEB+DB PRESS Vol.73｜gihyo.jp … 技術評論社

第5回ではRESTアーキテクチャスタイルを取り上げています。アーキテクチャスタイルとは何かという点、RESTをアーキテクチャスタイルとして採用することの意義なども解説しており、実際にRESTアーキテクチャスタイルでアプリケーションを開発していく流れをBEAR.Sundayフレームワークを使って解説しています。

• bearsunday - A resource oriented framework for PHP5.4 - Google Project Hosting
• koriym/BEAR.Sunday - GitHub
• BEAR.Sunday - twitter
• WEB+DB PRESS Vol.73 - BEAR Blog

なお、見出しアイコンにベア吉が採用されています。

PHPメンターズ道場生 kumamidori です。

PHPのエキスパートとして世界的に知られている方の１人に、Paul M. Jonesさんがいらっしゃいます。 フレームワーク「Aura for PHP」のリードであり、PHP-FIGの策定メンバーに入られている方です。 通称 pmjones さんのブログで、昨年末、DIに関する下記エントリがありました。 「Quicker, Easier, More Seductive: How To Tell A DI Container From A Service Locator」

興味深い内容のようだったので、翻訳しました。翻訳記事の公開について、著者ご本人から快諾頂けたため、掲載させて頂きます。 本文中にあるとおり、この記事に対する訂正として、「Quicker, Easier, More Seductive: Names, Usage, and Intent」という記事がありますので、併せてご確認下さい。 記事の内容について、皆様はどのように感じられるでしょうか。人によって、同意や疑問等、いろいろあるのではないかと想像します。

速く、簡単に、もっときれいに： DIコンテナとサービスロケータを区別する方法について

2013年12月16日 pmjones

違いをどう説明したら良いか

• クラスの新しいインスタンスを、サービス定義を持つことなしに、生成できるのならば、それはDIコンテナです。
• コンテナの外でオブジェクトを取得するのに、サービスを定義する必要があるのならば、それはサービスロケータです。
• クラスの新しいインスタンスを、サービスとしてそれを定義することなく生成することができないのであれば、それはサービスロケータです。

例

// これらは別々のインスタンスであり、サービスを共有していません
$foo_1 = $di->newInstance('Foo\Bar\Baz');
$foo_2 = $di->newInstance('Foo\Bar\Baz');
var_dump($foo_1 === $foo_2); // false

// __construct($gir) として与えられます
$di->params['Foo\Bar\Baz']['gir'] = $di->newInstance('Dib\Zim\Gir');

// セッタメソッドとして setOperation($operation_name) が与えられます
$di->setter['Foo\Bar\Baz']['setOperation'] = 'ImpendingDoom';

// 共有されるサービスを定義する
$locator->set('gir', function () use ($locator) {
    return new \Dib\Zim\Gir;
}

$locator->set('foo', function () use ($locator) {
    $foo = new \Foo\Bar\Baz($locator->get('gir'));
    $foo->setOperation('ImpendingDoom');
    return $foo;
});

// これらは共有されているサービスで、インスタンスは分離していません
$foo_1 = $locator->get('foo');
$foo_2 = $locator->get('foo');
var_dump($foo_1 === $foo_2); // true

誰が何をやっているか？

• Aura.Di: DIコンテナ
• Laravel Container: サービスロケータ　DIコンテナ
• Pimple (Silex などで使われている): サービスロケータ
• Slim (via $app): サービスロケータ
• Symfony DependencyInjection component: サービスロケータ (?!)
• Zend Di: DIコンテナ

分かったこと：

Laravel:

追記：

Pimple:

Slim:

Symfony DependencyInjection component:

結論

• 1. ポールがどんなルールを作ろうが、ある種の人たちが好きなシステムは本当にDIコンテナなのだ
• 2. そんな区別は実際大した問題ではない。どうなっていようが、好きなシステムを使えば良いだけだ。

コメントお待ちしております:-)

後書き

BEAR.Sunday Advent Calendar 2015 6日目の記事です。（※記事の公開が予定よりも遅れてしまいました。すみません。）

RESTfulフレームワークである BEAR.Sunday を使う機会がありました。 使ってみて考えたことを書きたいと思います。この記事では、まずコネクタとしてのリソース（BEAR.Resource）について説明します。リソースの単位を

　1. 名詞的情報にした場合と、
　2. ドメインユースケースにした場合

についてそれぞれ特徴を検討します。後者については説明用に動作するスニペットを組みました。

BEAR.Resource とは

BEAR.Sunday を構成するオブジェクトフレームワークの１つに BEAR.Resource があります。READMEには下記の記述があります。

BEAR.Resource はオブジェクトがリソースの振る舞いを持つHypermediaフレームワークです。 クライアントーサーバー、統一インターフェイス、ステートレス、相互接続したリソース表現、レイヤードコンポーネント等の RESTのWebサービスの特徴をオブジェクトに持たせる事ができます。

既存のドメインモデルやアプリケーションの持つ情報を柔軟で長期運用を可能にするために、 アプリケーションをRESTセントリックなものにしAPI駆動開発を可能にします。

リソースオブジェクトは、WebのURIと同じような page://self/index などのURIを持ち、HTTPのメソッド（GET/POST/PUT/DELETE）に準じたインターフェイスを持ちます。

コネクタとビジネスコンポーネントの関係

BEARでWebページを作る場合、「ページリソース」が「アプリケーションリソース」を呼び出す形になります。 アプリケーションリソースを使う意図について、フレームワーク作者の郡山さんに質問したところ、下記のような回答を頂きました。

Mike Amundsen(@mamund) さんの来日講演で、継続開発可能性のために、アプリケーションは情報を接続するコネクティングレイヤーとビジネスロジックのためのコンポーネントレイヤーの二層が必要だというのがありました。
BEARのリソースは前者の情報の接続のためのレイヤーです。

※コネクタ（接続レイヤー）とコンポーネントについての詳細は、資料 RESTとAPI設計のためのガイド / A Guide to REST and API Design eBook に記述があります。

アプリケーションリソースの基準は何か？

では、アプリケーションリソースの粒度、最小単位（= 再利用の単位）を何にするのか？考えてみたいと思います。

パターン１：リソースを名詞的情報とする

たとえば、公式チュートリアルの例だと下記です。

ref. bearsunday/MyVendor.Weekday

業務上意味のある名詞である情報をリソースにするパターンです。この基準を採る場合の特徴について、下記のように考えました。

• メリット：BEAR.Resource の諸機能（URI、リンク、外部アプリケーションのインポート、キャッシュ等）を細粒度から使える
• 課題：OOP、責務駆動設計、ドメイン駆動設計と蓄積されてきたような、型制約を活かした設計を採り入れる場合の実装方法？

たとえば、下記のような問題の構造をそのまま意図としてコードに表すのがDDDのビルディングブロックの考え方でした。クラスの型、名前、振る舞い等で部品の責務を限定することでリッチな語彙を作っていきます。

エンティティをリソースに、ユースケースをリソースに、サービスは？、URI制約から型への変換が要る・・・と実装を考えたときにうまくおさまらないように私は感じました。

パターン２：リソースをドメインユースケースとする

ユースケースクラスをリソースにインジェクトするパターンです。「Domain Kata」 のサンプルアプリケーションを見て、サンプルのモデル部分をBEARアプリケーションから呼び出すスニペットを実装してみました。（Doctrine 注入については文末掲載の参考リンクを参照させて頂き、助かりました。ありがとうございます。）

kumamidori/SnippetUserRegistration

• メリット：URIでユースケースの再利用が可能、モデルの意図性
• 課題：ユースケースから利用される側のクラスでは BEAR.Resource の諸機能がデフォルトでは使えない

２パターン挙げましたが、前者パターンで部分的にサービスをリソースにインジェクトする形もあります。 最後に、まとめ・・・としたいところですが、結論のようなものは現時点ではありません。 この記事を書くにあたって、こんな記事（奥さんに REST をどう説明したかというと…）を発見してのんびり読んだりして、楽しかったです・・・。

関連記事

• ドメインモデルのための型「Domain Kata」を使ってみました
• Kata #1 - サービス（SERVICES）

参考リンク

• BEAR.SundayでDoctrine2のORMを使ってみた（改） — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or something
• BEAR.SundayでDoctrine2のORMを使ってみた - Qiita

PHPメンターズプログラミング道場、最初のテーマです。

Symfony2のユーザー登録サンプルアプリケーション

• phpmentors-jp / phpmentors-training-example-symfony (GitHub)
  
  • 参照ブランチは1.2-2.2.1
  • 最初にGitHub上で上記リポジトリを自分のアカウントへforkする。その後自分のリポジトリをローカル環境へcloneし、masterブランチからdojoブランチを作成して作業する。最初はcomposerのcreate-projectからスタートする（composer installではない）
  • バージョン等はWikiページ参照。
  • 必ずローカル環境で動作するよう構築すること。ローカル環境とは、ソースコードの編集を行うOS環境と実際にプログラムが実行されるOS環境が同一であることを言う。
• コミットログを追う
  
  • 参照ブランチのコミットログを最初から順に追う。この時、最初はコミットメッセージだけを読んで、自分でやり方を想像してやってみること。
  • 自分の手元でも、参考のものと同じようにコミットしていくこと。
  • 自分が考えた実装と異なった点があれば、どう異なったのか、なぜ異なったのかを記録すること（後にブログ記事にまとめる）細かな違いにも気を配ること。
  • 概念などを理解するために自分で調べた際、参考にした書籍名やページ、ブログ記事ならそのURL等を記録すること。
• ブログ記事としてのまとめ
  
  • 作業中にメモした点、気づいた点、自分なりに調べて理解した点、メンタリングを通じて得られた理解を1本のブログ記事にまとめること。
  • 作業内容や概念等についての質問、記事の構成の仕方等は、随時アドバイスを求めてよい。ただし、道場入門生向けの情報共有グループを利用すること。
• 期間
  
  • 記事下書きレビュー予定：6月末

Symfony Advent Calendar JP 2012 - Day 25

「Pimpleでシンプルに正しくDIを理解する」の記事では、シンプルなDIコンテナPimpleにオブジェクトの依存関係の知識を集約する方法について解説しました。Pimpleの場合はサービスオブジェクトのファクトリーとして機能する無名関数の中に依存オブジェクトを記述しました。このように、実際に利用する依存オブジェクトを決めることをワイヤリングと呼びます。

今回は、ほぼ同一のオブジェクトモデルに対して、Zend Framework 2.0のDIライブラリ（Zend\Di）を使うように置き換えてみます。一般的にDIを扱う場合、依存関係の定義とワイヤリングのために何らかのコード―これは何らかの設定言語だったりプログラミング言語だったりします―を記述しなければならず、ある程度の規模以上のモデルクラス群をDIコンテナで管理する場合、定義のコーディング量がばかにならくなってきます。しかし、型を持ったプログラミング言語では、依存性注入メソッドの引数の型を調べることで、依存オブジェクトとして何が注入されることを期待しているのかを決定することができます。このようにメソッドの引数やその型について調べる機能をリフレクションと呼び、PHP5以降であれば利用できます。Zend\Diにはリフレクションを使った自動ワイヤリング機能が組み込まれているので、依存関係の定義やワイヤリングのためのコードの多くを省略することができます。

Zend\Diを使って書き換えたコード

<?php
require_once __DIR__.'/../vendor/autoload.php';

// インフラ
interface MailerInterface
{
    public function send($body);
}
class SendmailMailer implements MailerInterface
{
    public function send($body)
    {
    }
}


// ドメイン
class NewsletterTransfer
{
    protected $mailer;

    public function __construct(\MailerInterface $mailer)
    {
        $this->mailer = $mailer;
    }

    public function send($newsletter)
    {
        $this->mailer->send($newsletter);
    }
}

$di = new Zend\Di\Di;
$di->instanceManager()->addTypePreference('MailerInterface', 'SendmailMailer');

$newsletterTransfer = $di->get('NewsletterTransfer');
var_dump($newsletterTransfer);
$newsletterTransfer->send('ニュースレター本文');

Pimpleを利用したコードを見た後、こちらのコードを見ると不思議に思われるでしょう。DI用のコードがほとんどないため、Pimpleの例と同等であることが一見しただけでは分からないのではないでしょうか。このスクリプトを実行すれば、NewsletterTransferオブジェクトにきちんと依存性が注入されていることが分かります。

$ php test.php
object(NewsletterTransfer)#19 (1) {
  ["mailer":protected]=>
  object(SendmailMailer)#14 (0) {
  }
}

DI関連のコードとして唯一の部分は、最初にZend\Di\Diのインスタンスを生成した後、InstanceManagerにMailerInterfaceとSendmailMailerのワイヤリングを登録している箇所のみです。これ以外は、コンストラクタの引数のタイプヒントから自動的に依存オブジェクトの解決が行われます。ですので、Dependency Injectorである$diオブジェクトからNewsletterTransferクラスのインスタンスを取得するだけで、依存が解決した状態のオブジェクトを取得できます。

まとめ：ボイラープレートコーディングの削減 vs 意図の明示性

タイプヒントによる自動ワイヤリングは、ボイラープレートコーディングを大幅に削減します。ボイラープレートコーディングが大幅に減るので開発効率は上がりますが、その反面、DIにより注入されることを期待している、という意図の明示性は低下します。しかし、DIが技術として当たり前になった今、ごく単純な依存の定義に関しては、言語機能をシンプルに使うだけで機能するようになっていることのメリットは非常に大きいと筆者は考えます。

同じように自動ワイヤリングの機能を持つRay.Diでは、メソッド引数のタイプヒントとメソッドのアノテーションを組み合わせて記述するため、依存についての明示性も担保されています。優れたプロダクトですので、本ブログでも近いうちに紹介したいと思います。

参考

• Zend\Di (GitHub)
• Zend DI QuickStart
• Zend\DiをComposerでインストールする

2012年9月15日に大田区産業プラザPiOで開催されたPHPカンファレンス2012にて、「実践Dependency Injection」と題した講演を行いました。会場にいらしていただいた皆さん、ありがとうございました。また、このような場を提供していただきましたPHPカンファレンスの実行委員の皆さん、ありがとうございました。

• PHPカンファレンス2012
• 実践Dependency Injection // Speaker Deck
• 実践Dependency Injection講演Ustream

講演で使ったスライドは、以下です。会場のプロジェクタではコード部分等やや見づらかったかもしれません。こちらでご確認いただければと思います。

講演では、短い時間でしたがDIの基礎知識や誤解しやすい部分についての解説と、SymfonyのDependency Injectionコンポーネントの使用例や実践的な使い方、特徴についての解説を行いました。内容のまとめとして私がお伝えしたかった部分のみ、ここに再掲いたします。

• DIは、変更に強いクラスを設計するために必須の技術
• 実践で使われているDIコンテナ実装はすでにある
• 過去から蓄積されてきた汎用的な知見を学び、自分のソフトウェア開発に取り入れよう

当日の会場やUstreamで講演を見て下さった方、スライドだけでも見て下さった方、ありがとうございます。分かりやすかった、参考になった、もう少し●●の部分を詳しく聞きたい等、どんなことでもご意見をお聞かせ頂けたら幸いです。

• Twitter: @hidenorigoto
• Facebook: hidenorigoto

2018年1月10日に開催された DCI Tokyo 1 に続き、2018年3月27日に DCI Tokyo 2 が開催されました。今回も James Coplien @jcoplien さんをお招きしてのトークセッションとなりました。会場は 株式会社ヴァル研究所 様に提供していただきました。

セッションは、前回同様 @remore さんと @ganchiku さんによる同時通訳とともに進められました。

今回のテーマはマルチパラダイムデザイン（Multi-Paradigm Design: MPD）の中核を成し、DCI / リーンアーキテクチャ（Lean Architecture）とも深く関係する 共通性／可変性分析 でした。

レポートは @smori1983 が担当させていただきます。

当日の様子は Coplien さんの許可を得て YouTube の DCI Tokyo 公式アカウントにて公開されています。Coplien さんのおもしろTシャツにも注目しながら、ぜひご覧ください。

• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (Part 1 of 4)
• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (Part 2 of 4)
• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (Part 3 of 4)
• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (Part 4 of 4)
• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (extra)

全体の流れ

全体の流れとしては、1980年代以降のソフトウェア開発の歴史を、主にオブジェクト指向に対する考え方の変遷を通して振り返りつつ、MPD と DCI の関係性に迫るものとなりました。

オブジェクト指向（1988）

当時は C++ の他に、テレコム業界向け言語である CHILL や、軍需産業向け言語である Ada などの言語があり、それらの言語がオブジェクト指向なのかという議論がされていました。

最終的に C++ が残ることになりますが、C++ の作者である Stroustrup 氏は、そもそも C++ をオブジェクト指向言語ではなく、マルチパラダイム言語と定義していたことに注意する必要があります。

当時考えられていたオブジェクト指向の構成要素は次の3項目でした。

1. inheritance / 継承
2. polymorphism / ポリモーフィズム
3. instantiation / インスタンス化

1994年に Coplien さんは David Weiss 氏と Robert Chi Tao Lai 氏とともに仕事をしますが、その時、共通性／可変性分析を通じて、ソフトウェアファミリの振る舞いなどを特徴づけ、当時取り組んでいたソフトウェアのための DSL(Domain Specific Language) を開発しました。開発言語は C でした。

この、共通性に注目してグルーピングしたものをファミリと定義する方法は、Weiss 氏らが考案したFAST(Family Abstraction Specification Technique) という手法に基づいています。

DSL は小さなドメインを対象にしていて、ドメインが変化しない限りはうまくいったそうですが、ドメインは変化していくものです。DSL は、デバッガなど周辺技術との密な関係性の中で成立するため、その変化に対しては脆いという問題がありました。

ただし、共通性／可変性分析自体は非常に有用で、ドメイン分析に対しては非常に多くの収穫があったそうです。

分析の結果得られる共通性／可変性テーブルの内容の埋め込み（注: 解決ドメインの抽象による実装）に関して、

• DSL で埋め込むと、固くなりすぎ、脆くなる。
• C で埋め込むと、言語特有の制約が多く、開発者の intentionality（意図）がわからなくなる。

という課題がありましたが、C++ を用いることで、よりうまくいくようになりました。

オブジェクト指向（1995）

Coplien さんは、C++ を

共通性／可変性分析のための、汎用言語キットである

と捉えます。

その視点で見たオブジェクト指向は、次の4項目の構成要素で理解されるようになりました。

1. Common Signature
2. Common Data
3. Variation in Data
4. Variation in Algorithm

また、polymorphism / instantiation は、共通性／可変性のバインディングタイム（注: 共通性／可変性が変数に束縛されるタイミング）の選択の問題として捉え直されることになりました。

オブジェクト指向（DCI 時代）

Coplien さんによれば、更にこの後、3段階の気付きを経て、現在のオブジェクト指向理解へとつながっているそうです。

1段階目: There  is no OO in C++

• 2010年くらいまでは、オブジェクト指向という言葉を、抽象データ型（ Abstract Data Type: ADT ）という意味で使っていた。
• C++ は実際には抽象データ型ではなく、具象データ型（ Concrete Data Type: CDT ）であるということ。

2段階目: There are no objects in source code

• C++ プログラムはソースコードである。
• そこにはオブジェクトは存在しない。ソースコードに記述しているのはクラスである。
• 多くの人々が Java などの言語でやっているのはクラス指向プログラミングである。

3段階目: OO is mental model

• Trygve Reenskaug 氏とオブジェクトとは何か、オブジェクトパラダイムとは何かについて話し合い、DCI が生まれた。
• DCI は、抽象データ型の実装を意味したこれまでのオブジェクト指向とは別の視点を与える。
• 実行時におけるオブジェクトのネットワークがどのように問題を解決するかに注目する（ Alan Kay の定義）。
• 我々はクラスとロールをごちゃまぜにして考えていた。
  • 抽象データ型について考えるのがクラス指向。
  • ロールについて考えるのがオブジェクト指向。
  • 抽象データ型＋インスタンス化がロールを実行（play）。

MPD と DCI

MPD は、クラス指向のレイヤーにおいてドメイン分析を行う時、ソフトウェアファミリの共通性／可変性分析を通じてドメインモデルを構築する手法を提供します。

DCI は、我々のメンタルモデルに基づいて、オブジェクトどうしの相互作用を定義します。そこでは、抽象データ型としてのクラスに具体的なロールを注入されたオブジェクトが、特定のコンテキストのもとに配置され、相互作用するという、動的な側面を捉える方法を提供します。

以上を簡単にまとめると、次の表のようになるかと思います。

歴史的には MPD が先行しました。それは後に、モデルの静的な構造の分析を行うための領域を担う設計方法論という捉え直しがされました。そして、オブジェクト指向に対する新しい視点を提供する DCI が、クラス指向では扱うことが難しかった、モデルの動的な関係性を捉えるための方法論として提起されています。

Time and Space と DCI における共通性／可変性

DCI は、オブジェクトどうしの相互作用に注目します。つまり基本的には時間の経過（シーケンス）が意識されます。しかし、あるロールを付与された複数のオブジェクトが配置されてこそ、相互作用が成立するものです。

コンテキストとは、このように、ある状況に参加する主体の空間的配置と時間的な相互作用の総体として捉えられるものと言えます。

ここで、日本人にとってはありふれた「間」という概念が取り上げられました。具体例としては次のようなものが話題にあがりました。

• 歌舞伎（ Coplien さん）
• 龍安寺の石庭（ @koriym さん）

また、アレグザンダーの考案したパターンランゲージに話が及びました。パターンランゲージは、建築の構造（空間的なパターン）だけではなく、その構造が生み出す人々の相互作用（時間的なパターン）も内包したものとして理解されるべきです。

pattern of behavior = pattern in space + pattern in time

セッションの終盤では、このように、DCI が担う領域における共通性／可変性概念の適用可能性が示唆されました。

さいごに

会場を提供していただきましたヴァル研究所様、DCI Tokyo スタッフの皆様、今回もすばらしいイベントとなりました。ありがとうございました。

次回は、ワークショップ形式での開催も視野に入れながら、DCI Tokyo 3 が開催されることと思います。MPD / DCI / Lean Architecture に興味のある方は、ぜひご参加ください。