後半のセッションでは、「What the system is（共通性や可変性を分析する）」を説明しつつも、「What the system does」とは別のものとして切り分けることはできないという主張から、 DDD とリーンアーキテクチャとの比較、そしてパターンに関する議論が展開されました。 @remore が前半部分をまとめてくださっていまして、そこで出て来るいくつかの用語（Form, Structure, What the system is, What the system does）を前提として私のできる範囲で行いました。
なお当日のCoplien氏によるセッション内容は、許可を得た上でYouTubeにアップロードされていますので、より深くご覧になりたい方はこちらも併せてご参照下さい。
What system is に関して
Jim Coplien さんの言うアーキテクチャ
- 共通性、可変性分析に関する What system is に関連している。
- ほとんどのドメイン知識は、アルゴリズムで表される What system does よりも What system is の方にある。
ソフトウェアを開発する際に重要なもの
- プログラム言語自体の知識ではなく、ドメインでありビジネスである。
- ほとんどのドメイン知識は、構造(Structural)であって、アルゴリズムではない。
このミートアップでは、構造(Structure)の方を主に扱う。What system is の方である。
- 実際のシステムを構築する際には、構造は安定されていることが多いので先に行うことが多く、それらが出来上がってから、まだ実装されていない機能を作り始める。
- その機能が、人々が求めているユースケースになり、これがビジネスとなる。
What system is と What system does の関係性
しかし、What system is と What system does は別々に考えられるものではない。それは、構造と時間やアルゴリズムを全く別のものとして、分けることは不可能だからである。
リーンアーキテクチャ本では、 What system is も What system does も説明しており、夫婦で共著で書いている。
リーンアーキテクチャ本では分けることができると書いたが、実際は簡単に構造とユースケースを分けることができるわけではない。
それは、歴史が物語っている。
- 1960年から1970年では、ノイマンコンピュータでは、データ構造は全く注目せずに、 What system does に注力され、 CPU が大事でこの性能を良くするということが重要だった。
- 1970年後半にデータベースが登場し、ボトルネックはデータへのアクセス速度が重要となった。CPU のことは忘れ去れられ、What system is が注意の関心の的になり、データモデルが重要になった。
- 1980年にコンピューターネットワーキングが登場し、オブジェクト同士のコミュニケーションが重要になった。こちらは What system does がまた注目された。
このように、歴史を見ると、 What system is と What system does のサイクルができている。
アーキテクチャ全般に言えることだが、例えば部屋の構造では、どこにライトがあって、どこドアがあって、それが何か(What system is)を説明することができるが、どうしてそこにある(What system does)のか、とか、部屋の中をどうやって歩くかなどのプロセスにも影響している。つまり、これらは簡単に分けることはできずに互いに関係しあっている。
リーンアーキテクチャと DDD の関係性
DDD
- 分析に関しては扱っていない。
- コードに関することを主に扱っている。
- 形態(Form)の社会性は扱わない。
- 構造(Structure)のみに注目しており、具体的な事柄から始める。
リーンアーキテクチャ
- 人々について、そして人々のメンタルモデルを扱う。モデルに関する議論をすることを扱っているので、社会的な活動である。
- 形態(Form)を扱う。
- 形態(Form)からスタートして、抽象的な Commonality から Variation を適用させて正しい実装をしていくことである。
アレグザンダーは、アーキテクチャは、社会的な活動であると明記している。
対称性とパターンに関して
アレグザンダーは、空間からイベントのパターンを作成している。ソフトウェアはまだ歴史が浅いため、パターンはほぼ存在しない。建築は世紀を超えてパターンを作ってきた。ソフトウェアの世界で言われているパターンは、コンテキストの上でのロジックであって、それはパターンではない。唯一、例として上げてもらったパターンは、リーキーバケットに関するものであり、イベントのパターンを説明している。
リーキーバケット
共通性と可変性は対称性を持っているが、あるとき対称性が壊れることがある。プログラム言語では対称性を表そうとするが、実際の要件では、対称性のない複雑なものを作り上げる必要がある。リーンアーキテクチャは対称性を扱っており、負の可変性(Negative Variation)は扱っていない。ここが複雑な場所である。パターンは、What system is と what system does の両方を考える必要があり、また、空間と時間を考える必要がある。
パターンに関する議論に関しては、私(ganchiku)の中で消化しきれていない場所があり、まとめることができませんでしたので、今後の課題としてアレグザンダーや Jim Coplien さんの議論を追いかけて、自分の言葉で説明できるようになっていこうと思います。
会場を提供していただいた UUUM 株式会社、また、オーガナイズしていただきました DCI Tokyo メンバーの皆様ありがとうございました。