ドメインモデルとクラウドリソース

前回「ドメインオブジェクトとデータストアのマッピング」の検討は、SimpleModelingが元々定義しているドメインオブジェクトを検討対象にしています。つまり、クラウド登場前のドメインオブジェクトですね。伝統的なドメインモデルを、クラウドアプリケーションが扱わないといけない多種多様なデータストアにどのように格納管理するのかというのがテーマです。

それとは別の次元で、クラウド時代に入ってドメインモデルのスコープやドメインオブジェクトのモデル化対象をオーバーホールして見直す必要があると感じています。

クラウド時代以前のドメインモデルは基本的に自前でデータベースで管理するオブジェクトが中心で、システム外のオブジェクトはアクターという形で特別扱いして凌ぐ形になっています。

一方、クラウドアプリケーションの場合、複数のサービスをマッシュアップして構築するのが主流となるため、利用者のメンタルモデルに登場するオブジェクト、すなわちアプリケーションが扱うオブジェクトは、必ずしも自前のデータベースで管理するオブジェクトとは限りません。場合によっては、ほとんどが外部オブジェクトということになるでしょう。そのようなケースでこれらをアクターとしてモデル化するのは明らかに不適切です。

この問題に対応するには以下の2案が考えられます。

1. ドメインモデル(PIM段階)を概念モデル的な抽象度の高いモデルと位置づけ、設計時(PSM段階)に自前データベースか他サービス上のリソースかをモデル化する。
   
2. ドメインモデルの初期作成段階(PIM段階)からサービス上のリソースを専用のオブジェクトで表現する。

(PIM=Platform Independent Model=プラットフォーム独立モデル、PSM=Platform Specific Model=プラットフォーム固有モデル)

つまり、ドメインモデルを構成するオブジェクトとしてクラウド上のリソースを一級市民として扱うのか否かという問題ですね。

メタモデルとしての汎用性、拡張性という意味では前者(クラウドリソースをドメインモデルの一級市民として扱わない/PSM段階で導入)が美しいと思います。

しかし、クラウド時代にはクラウドサービスの活用がアプリケーションの中心的な関心事の一つであり、利用者自身も使用しているリソースとリソースを提供しているサービスの関係を意識するケースも多くなるため、PIM段階で自前データとクラウドリソースを明確に区別しておいたほうがなにかと得るものが多そうです。

また、設計実装との連続性という意味では、自前とサービス活用ではアプリケーションの構築のアプローチが異なってきます。PIMレベルのドメインモデルを構築した段階で、ざっくりとした工数見積もりができることも重要で、そういう意味でも自前オブジェクトとクラウドリソースをPIM段階で分離しておくのが実用的なアプローチであると考えています。

また、前者の美しいアプローチで起きそうな問題点として、自前リソースとクラウドリソースのアクセススピードの問題もあります。これは、複数のサービスの共通部分を抽出、汎化して、適切な抽象度のインタフェース経由で提供することができても、性能差がありすぎると事実上同じようには使えないという問題です。

たとえば、WebDavをExplore(Windows)やFinder(Mac)の配下に置いてExcelファイルなどをクリックで開いて使う使い方はとても便利ですが、UNIX shellの上からfindしたりとかそういう細かい使い方をしようとすると速度が遅すぎて心が折れてしまいます。後者のような使い方の場合、サービスに処理プログラム(クロージャ的な物)を投げてサービス側で処理を実行するエージェント的なアプローチ(レトロな言い方ではRJE(Remote Job Entry)かな)の方がより適切です。(WebDavは残念ながらこういう使い方はできませんが、これからのクラウドサービスではこういった利用方法への対応も重要な課題になると思います。)

また、細かいところでは故障頻度にも相当大きな差が出てきます。故障発生確率の大小で利用者への見せ方が変わってきます。加えて、障害発生時の可用性の問題も重要です。マッシュアップしている多数の外部サービスの一つが落ちただけで、自サービスがまるごと動かなくなるのは、アプリケーション的にはかなり恥ずかしいので、自サービスの根幹部と周縁部を切り分け適切に責務分割を行うことが必要です。

こういった要件の実現はアプリケーションアーキテクチャの根幹に関わってくるので、PSM段階から意識を始めるのはやや遅い感じで、PIM段階で意識の上に上げて起きたいところです。

今の所、以上のようなことを考えながら、机上で試行錯誤している状況です。たとえばドメインオブジェクトの種別DomainResourceを自前リソースと位置づけ、クラウド側のカウンターパートにCloudResourceやServiceResourceといったオブジェクトを新規に導入するのか、というようなことを検討しています。