速さが足りない

プログラミングとか、設計とか、ゲームとかいろいろ雑記。

ドメイン駆動 - コンテンツ管理 (3)

前回の記事はこちら(リンク先)からどうぞ。


さて、変更に強いとは言ってもどうすればいいのでしょうか?
今流行りつつあるドメイン駆動設計でしょうか?
ちょっと古いSOA(service oriented architecture)でしょうか?
railsや組み込まれたMerbの様々な概念を使うことでしょうか?



まあたくさんありますよね。人それぞれ、プロジェクトそれぞれ、会社それぞれに解決方法はあると思いますが・・・
今回はあまり知られていない概念モデルを使っていこうと思います。
使って行こうといいますか、今回の問題を概念モデル化して、ドメイン駆動におけるモデルを洗練させていく作業に近しいでしょうか。
概念モデルやそれのパターン(アナリシスパターン)をもっと詳しく知りたい!という方はこちらの書籍(リンク)が素晴らしいです。ドメイン駆動設計(青の方)と合わせてぜひ一読して欲しい、とオススメできる一冊です。


さて、最初は「なぜ概念モデルなのか」というところです。
ちょっとだけITコンサルタントの業務になってしまいますが、あるサービスを新規リリースする際やリプレースする際に

  • こういうシステム構成で
  • こういうアプリケーションを作って
  • こういう運用体制で
やってみるとxxパーセント売上が上がったり、コスト圧縮できたり、等のメリットがありますよ、と提案する訳ですね。


あるシステムのリプレースが特に分かりやすいですが、この提案をする際にコンサルタントが問題を解決する手法には幾つかあり、その1つが

  • 今どんな(システム・運用の)問題を抱えているのか
  • 問題だらけの現状に対しての、理想的な状態
  • 理想に向けて解決すべき問題と解決方法
現状を分析し、理想像を描き、その差をどのようにして解決していくか、になるわけです。


さて、実際に前回の記事で問題となった点を挙げてみましょう。

  • テーブル構造が肥大化している
  • テーブル構造が複雑化している
  • 変更の度にテーブルが変更されるため再起動(メンテナンス)が必要
  • 数限りなくある端末やOSの組み合わせの登録が運用コストを上げている
等でしょうか。実際はもっとあると思いますけどね。
今回の主題ではないので置いておきますが、ちょっと言及すると、アプリケーション(ファイル)の肥大化によるストレージ容量の逼迫、N/W通信量の肥大化、等でしょうか。

話を戻しましょう。
「テーブル構造が肥大化・複雑化する」のは理想の状態ではないからですよね。
そもそも理想ってなんだ?という話になりますが、1つの解決方法として「実際に存在するモデル」から「概念的に考え得るモデル」にして、モデル間の構造を考えてしまえば、概念的には実際に存在するモデルを全て包括する訳ですから、理想と言えますね。
よく分からない話になってきましたね。
簡単な例を挙げましょう。
「記事・アプリケーション」があります。この記事のタイトルにもなっていますが、どちらも「コンテンツ」ですよね。
業務モデルの「記事・アプリケーション」を「コンテンツ」としておけば、ニュースも広告も、静止画像も、動画もみんな「コンテンツ」ですから、どんな変更がきても包括されるという訳ですね。

ということで、今回の概念モデルは「テーブル構造が肥大化・複雑化」する問題に対する理想を作るというものであって、

  • 変更の度にテーブルが変更されるため再起動(メンテナンス)が必要
  • 数限りなくある端末やOSの組み合わせの登録が運用コストを上げている
に対する理想にはなりませんのでご了承ください。



前置きが長くなりましたが、スタート地点はよく出てくる業務モデルです。1回目の記事で使った業務モデルを見てみましょう。

f:id:geane:20160304162404p:plain

はい、これについて抽象的な概念にまで持っていければよい訳ですね。
しかし、1つの実際にする存在するモデルは、概念をそぎ落として実装されたものですから、1つだけを見ると概念モデルが不完全である可能性があります。
実例で考えましょう。

f:id:geane:20160310114351p:plain

コンテンツの実例としてアプリケーションや動画、記事などがある訳ですが、ここで既に差があります。アプリケーションには長さという概念がなく、動画、記事には価格という概念がありません。
まあ動画は無料動画とか有料ストリーミング動画とかありますから、価格という概念は出てきやすいかな、とは思いますけど一旦置いておきましょう。
ここでもしアプリケーションというコンテンツを考慮せずに動画・記事という業務モデルのみで概念モデルを形成した場合は、価格という概念が抜け落ちてしまう訳です。
実際は、当然概念が抜け落ちることがありますし、アナリシスパターン化するには、3回くらいはリリースしたシステムのドメインに対してではないと知見が足りなく上手くいかないと言われる所以ですね。

さて、一気に進めましょう。コンテンツと言われるものを集めて、属性を集約してみましょう。

f:id:geane:20160310123148p:plain

こんな感じでしょうか。コンテンツに含まれる概念は不足していますが、今回の主題にしたいところではないため省略としています。
また、今回は完全な概念モデルを作るのではなく、あくまでも導入ですのでこれくらいにしておきましょう。


次はコンテンツの属性について見ていきましょう。
前回の記事では「表示する端末」は厳密に記述すると「コンテンツを表示する端末・OS組合せの一覧」ですね。要はブラックリストです。
更に掘り下げると「コンテンツ」の「表示を許可」する「端末・OS組合せ」の「一覧」ですね?
ということで、ブラックリストホワイトリストを図にしてみましょう。

f:id:geane:20160310130633p:plain

さて、「表示許可」「表示不許可」について掘り下げていきましょう。
あるユーザが特定の端末OSでアクセスした際に表示「できる・できない」条件ですね。
つまり、一般的によくあるログインユーザの所持権限によって、機能を実行「できる・できない」条件と似た構造な訳です。
この権限をヒントに文脈を掘り下げましょう。つまり、
あるユーザが特定の端末OSでアクセスした際に、権限が付与されていた場合に表示「できる・できない」条件ですね。
この概念を元にもう少し概念モデルに近づけましょう。

f:id:geane:20160310132102p:plain

つまりこういう事ですね。あるユーザが特定条件(指定端末)でアクセスした際にはコンテンツを表示する権限を有するため、コンテンツの表示が可能と。

さて、コンテンツの属性について、この表示権限と同じ概念のものを探していきましょう。
ぱっと見た限り「公開開始日」「公開終了日」「プレミアム対象」「年齢レーティング」が合致しそうですね?細かく見ていきましょう。

  • 公開開始日~終了日は表示権限の可否は可で、演算としては以上・以下・一致、権限タイプ・・・としてはつまりコンテンツドメインに含まれる要素「公開日」を「基準値」にしている
  • プレミアム対象権限の可否は可で、演算は一致(もしくは以上)、基準値はユーザドメインのユーザ種別(フリー・通常課金・プレミアム課金・カスタマーサポート・システム管理者等)
  • 年齢レーティングは表示権限の可否は可で、演算は以上・以下、基準値はアクセス者の生年月日もしくは年齢、年齢別アクセスチェック(確認)の可
ということですね。
これらを踏まえてもう少しこの概念を成長させてみましょう。

f:id:geane:20160310134204p:plain

大まかにいくとこんな感じでしょうか。この構造によって表示権限が増えたとき、例えばコンテンツを表示するための条件としてシンジケーション(収益対象化のプラットホーム)からのアクセスのみ表示を行う、という要件が加わったときに、コンテンツ自体やその関連に変更はなく、表示権限の実装の1つとして、ユーザ・端末OS組合せと同じ階層に「ユーザのアクセス元」が基準値として加わるわけです。
このシンジケーション要件例は、記事のPVを元にユーザに何かの価値(お金、ポイント等)を提供する際に、PVにはRSSで参照されたPVを表示したくないという事ですね。
RSSには広告を任意に含めるのは難しいですし、ブログとしての広告媒体という意味で見られていない訳でありRSSにシンジケーションは含めない、という要件例であればこの概念ドメインにマッチすると思います。




さて、もう少し表示権限のみを掘り下げましょう。
この表示権限は複数の責務を担っています。それは

  • 表示の可否
  • 入力値の算出
  • 基準値の算出
  • 演算方法
  • 演算(判定)
です。つまり「記事」が「プレミアムユーザ対象記事(基準値の算出)」の場合、「アクセスユーザ(入力値)」が「プレミアム課金者(演算・演算方法)」でなければ記事を参照する権限を持たない訳です。

もう少し概念的にいきましょう。
結局のところ、ある2点間「アクセスユーザのプレミアム課金」「記事のプレミアム対象」における関係がどうなのかを演算する責務と、2点間を割り当てる責務がある訳ですね。
つまり、2点間を割り当てする責務はどうなるべきでしょう。
2点間を割り当てるということは、その2点が概念的に等価、等級が同一といいますか、を知っている必要がある訳ですし、同一にする責務を負っているはずです。つまり算出は、単なるプロパティの選択ではなく、値の変換を含めた導出です。
よって、「入力値の算出」「基準値の算出」はある値の導出を行うものであり、「表示権限」ではないため、導出責務として独立し、表示権限は導出責務を知るという責務だけあればよい訳ですね。


例を挙げてみましょう。
年齢レーティングというものがあります。R15やR18ですね。
ある記事が18歳以上でなければ参照する権限がない、ということは2点は「記事に設定された年齢レーティング(から算出される実際の年齢)」と「アクセスユーザの生年月日(から算出される年齢)」になりますが、この概念的には異なる2点を同一概念に変換する必要があります。
さて、立ち戻って結局のところこの概念は「表示権限」ですから、異なる2つの概念を同一にする訳ではないですよね。


さて、まだ3つ残っていますね?
ということでそちらも探求してみましょう。
カンの良い方はもう理解してそうですが、つまるところ表示の可否と演算方法はどちらも演算であって一緒ですよね。
そして、導出責務と同じく、表示権限が演算の内容を知る必要はなく、パッケージされた演算手法のみを知る責務があるわけです。
結局のところ、表示権限は「導出責務」と「演算責務」の関係を作動させる責務がある、という事です。

ここまでを図にしてみましょう。

f:id:geane:20160330200709p:plain

はい、随分簡単になりましたね。残りはもう少しです、頑張りましょう。
ということで次です。
結局表示権限となりましたが、この検索する際の条件は1つではなく複数になるはずです。
「記事がプレミアム対象の際は、ユーザがプレミアム課金者」「記事が公開済である」「現在時刻が記事の公開日より未来である」等です。
これについて考えてみましょう。
導出責務(入力値の算出)が「記事がプレミアム対象の際は、ユーザがプレミアム課金者」の「表示権限」の導出責務・演算責務を関係した結果になりそうですね?
そして、導出責務(基準値の算出)が「記事が公開済である」になり、演算責務は「論理和」になる訳です。
つまり、表示権限は子要素となる表示権限を持つ場合がある、ということですね。

ということでこうなりました。

f:id:geane:20160330201947p:plain


さて、次は違う例にいってみましょう。
経験豊富な方ならお気づきかも知れませんが、ここで扱うのはそう、「長さ」についてです。
コンテンツについて様々な実体ドメイン、つまり動画・記事・アプリケーション・ニュース・音楽等々があるわけですがから、長さと偏に言っても「文字数」「再生時間」等ですね。

このままドメイン設計の観点から言ってしまうと、コンテンツというドメインの概念には長さを表すValueObjectが1つあり、長さを表す。実ドメインとしての動画ドメインであれば長さというValueObjectは再生にかかる長さを表すものである。となってしまいますね?

しかし待ってください、我々が本当に知りたいのは、「長さ」ではないでしょう。YouTubeで動画の長さ(再生時間)を見て「再生時間はコンテンツを消化する時間」と認識しているはずです。
消化というのはつまり、参照したコンテンツからユーザが期待した結果を得られるまでの時間、ということです。

例を挙げてみましょう。
ブログ(記事)の長さの基準に文字数というものがあります。この記事の文字数だけ見ても参照する人にとっては何の参考にもなりませんね?そう、記事の中に動画やスライドが含まれていればその記事を読んでいる時間が延びるはずです。

つまり、長さとは平均再生時間であり、平均読破時間であり、ユーザがコンテンツから期待した結果を得られるまでの時間
、「平均的に参照するまでの参考値」という事ですね。
その1つに文字数であったり、動画の長さがあるという事です。
更にいうなら、単純な再生時間、つまりコンテンツを参照する最大時間も持つべきです。
つまりコンテンツは複数の長さを持つ、ということですね。

ここでコンテンツは複数の長さを持つ、としてドメインの概念を理解することによって、最終的に実装される「コンテンツ」テーブルに長さを持たず、「コンテンツ長さ」テーブルという関係テーブルに長さを持つことによって、容易にコンテンツの参照の参考値となる長さを追加できる訳です。


さて、今回はここまでです。
例に挙げたコンテンツと表示権限と長さの概念が全てに当てはまるかというときっと知見が足りません。
世には色々なデジタルコンテンツのサービスがありますから、もっと素晴らしい概念が含まれているかも知れません。
毎回このドメインの概念を探求していくべきですし、ドメインが進化していく以上完成はないわけです。

しかし、ここで用いたアナリシスパターンでブログシステムを構築した後に、動画配信サービスを構築する際はドメインモデルのスタートとしてきっと役に立つと思いますし、真っ新からスタートした状態よりは堅牢なドメインモデルを作りやすいはずです。
そういうことで、このドメインへの探求(の入り口)への手助けになれば、と思います。

なお、時間に余裕ができたら実装編ということでコンテンツ管理(4)に続きます。