DCI Tokyo 1 - Lean Architecture by James Coplien - が開催されました（後編）

後半のセッションでは、「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 メンバーの皆様ありがとうございました。