Zerobase Dev Blog

コードネームYentry

DCIアーキテクチャ

オブジェクト指向ユーザーインターフェイス(OOUI)とドメイン駆動設計(DDD)みたいなことを考えていたところ、和智さんDCIアーキテクチャ を教えてもらった。面白い!

メンタルモデル中心ソフトウェア・デザインパラダイムは、ぼくの考えている「UIデザインと内部デザインの一致」に役立ちそうだ。しばらくDCIについて調べてみる。

DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism

実はわれわれは皆、頭の中に資金の振替に対する一般的なモデルを持っているのであり、これはそこに含まれる口座がどんなタイプであるのかということに依存しない。このようなモデル、つまりインタラクションこそ、ユーザの頭からコードへと写し取りたいと考えているものなのである。

...

旧態依然としたオブジェクト指向は、とりわけこのような適切な粒度("fine-grain")のメソッドを作るよう推奨する。例えば、典型的なSmalltalkのメソッドは3行なのである。

オブジェクト指向9つの簡単なルール

...

これはユースケースをほぼ逐語的に展開したものである。エンドユーザのメンタルモデルに見られる、ロジックの自然な構成に従ってロジックが多くのクラス境界に分散しているのと比べると、この方が理解しやすい。われわれはこれをメソッドフルなロールと呼ぶ。

...

DCIによって解決される根本的な問題は、人々がオブジェクトと呼ばれる統合された単一のものについて、頭の中で2つの異なるモデルを持っているというものだ。1つはシステムが何かについてのデータモデルであり、それは銀行とその口座について考える際の助けとなる。もう1つがシステムが何をするかについてのアルゴリズムモデルであり、これは口座間での資金の移動に関するようなものだ。

...

ユースケースシナリオから切り取られた一連の操作がロールと呼ばれるものだ。これらについて、コンパイル時には閉じた形(ソースコード)においてとらえたいと思うし、対応するユースケースが実行時にやってきた時にはオブジェクトがそれをサポートできるようにしたい。したがって、図4に示すように、あるクラスのオブジェクトはそのクラスのメンバ関数をサポートするだけでなく、どんな時でもそれが演じるロールのメンバ関数を、あたかも自分のものであるかのように実行できなけれあならないのだ。つまり、ロールのロジックをオブジェクトに注入し、それによって、オブジェクトがインスタンスの構築時にクラスから受け取るメソッドと同じように、ロジックがオブジェクトの一部となるようにしたいのだ。

...

アルゴリズムとロールからオブジェクトへの紐づけを行うのはコンテキストオブジェクトである。特定のユースケースにおいて実際にアクタとなるオブジェクトをどのように探し出せばよいかということをコンテキストは「知っている」のであり、ユースケースシナリオにおいて適切なロールに「キャスト」するのだ(ここで「キャスト」という単語は演劇的な意味で使っている。ただ、もしかしたら、いくつかプログラム言語の型システムにおける意味もあるかもしれない)。

...

  • データ:これはドメインオブジェクトの中にあり、ドメインクラスに由来している。
  • コンテキスト:要求に応じて、アクティブなオブジェクトをシナリオにおけるポジションに位置づける。
  • インタラクション:ロールの観点からエンドユーザのアルゴリズムを記述するもの。ロールもアルゴリズムもエンドユーザの頭の中に存在する。

...

預金口座コンテキストは「高次の」コンテキストオブジェクトによって、ドメインオブジェクトとして使用され、下位のコンテキストオブジェクトを呼び出すことができる。これは多層のドメインモデルをサポートする強力な概念だ。

...

問題はこれをどうやって実現するかということだ。そしてその結論が、トレイトと呼ばれる概念である。ロールが(エンドユーザの頭の中から引き出すための)分析概念であるとすれば、トレイトはロールを表象する汎用的な設計概念である。そしてその実装はプログラミング言語によって異なる。例えば、C++においてトレイトは、メンバ関数がコンパイル時に具象クラスとコンポーズされるテンプレートとして表象される。それによってオブジェクトは実行時にクラスのふるまいとテンプレートのふるまいの両方を実行できるのだ。

...

Scalaにおいてトレイトは、なんとトレイトと呼ばれる言語の構成概念によって実装される。このメソッドはオブジェクトに対してインスタンス生成時に注入されるのだ。

...

  • ユースケースが示す要件に現れるような、ユーザが持つ主要な概念をとらえるために、われわれはロールを用いる。

  • 経験や暗黙の知識に由来する深いドメインの概念をスマートデータとして表現するためにオブジェクトを用いる。

  • ソフトウェアはオープンクローズ原則を表現する。オープンクローズ原則が継承だけに基礎をおいていては、貧弱な情報隠蔽という結論に至る。DCI形式によって、ドメインクラスとロール両方の統合が保たれる。クラスは修正に対して閉じられ、ロールを注入することにより、拡張に対して開かれる。

  • DCIはアジャイルソフトウェア開発と自然に整合する。DCIによってプログラマは、エンドユーザのメンタルモデルと直接的につながることができるようになる(このことは、単に顧客がプロセスやツールの代わりに、エンドユーザとのインタラクションに従事できるようにするということを凌駕している)。したがって、顧客が持つ共通語彙を使用し、顧客と並んでコードを読むことができるようになる(契約交渉よりも顧客とのコラボレーション)。タスクの順序の形式について論理的に考えることができる(このことは動作するソフトウェアを提供するチャンスを飛躍的に向上させる。少なくともプログラマがこれを理解できるのであり、エンドユーザのメンタルモデルと変換する距離ははるかに短くなるからだ)。そして、大事なことだが、これによって頻繁に変化するユースケースの部分と、安定したドメインの部分が分離されるのであり、そのことで変化が受け入れられる。これらのメリットはアジャイルマニフェストhttp://www.agilemanifesto.org)の条項に直接結びつけられるものだ。