速さが足りないスマートフォン用の表示で見る速さが足りないプログラミングとか、設計とか、ゲームとかいろいろ雑記。この広告は、90日以上更新していないブログに表示しています。前回の記事はこちら(リンク先)からどうぞ。architecture)でしょうか?railsや組み込まれたMerbの様々な概念を使うことでしょうか?まあたくさんありますよね。今回はあまり知られていない概念モデルを使っていこうと思います。使って行こうといいますか、今回の問題を概念モデル化して、ドメイン駆動におけるモデルを洗練させていく作業に近しいでしょうか。概念モデルやそれのパターン(アナリシスパターン)をもっと詳しく知りたい!という方はこちらの書籍(リンク)が素晴らしいです。ドメイン駆動設計(青の方)と合わせてぜひ一読して欲しい、とオススメできる一冊です。最初は「なぜ概念モデルなのか」というところです。ITコンサルタントの業務になってしまいますが、あるサービスを新規リリースする際やリプレースする際にこういうシステム構成でこういうアプリケーションを作ってこういう運用体制でやってみるとxxパーセント売上が上がったり、コスト圧縮できたり、等のメリットがありますよ、と提案する訳ですね。現状を分析し、理想像を描き、その差をどのようにして解決していくか、になるわけです。実際に前回の記事で問題となった点を挙げてみましょう。数限りなくある端末やOSの組み合わせの登録が運用コストを上げている等でしょうか。実際はもっとあると思いますけどね。今回の主題ではないので置いておきますが、ちょっと言及すると、アプリケーション(ファイル)の肥大化によるストレージ容量の逼迫、N/W通信量の肥大化、等でしょうか。「テーブル構造が肥大化・複雑化する」のは理想の状態ではないからですよね。そもそも理想ってなんだ?という話になりますが、1つの解決方法として「実際に存在するモデル」から「概念的に考え得るモデル」にして、モデル間の構造を考えてしまえば、概念的には実際に存在するモデルを全て包括する訳ですから、理想と言えますね。分からない話になってきましたね。簡単な例を挙げましょう。「記事・アプリケーション」があります。この記事のタイトルにもなっていますが、どちらも「コンテンツ」ですよね。業務モデルの「記事・アプリケーション」を「コンテンツ」としておけば、ニュースも広告も、静止画像も、動画もみんな「コンテンツ」ですから、どんな変更がきても包括されるという訳ですね。数限りなくある端末やOSの組み合わせの登録が運用コストを上げているに対する理想にはなりませんのでご了承ください。前置きが長くなりましたが、スタート地点はよく出てくる業務モデルです。1回目の記事で使った業務モデルを見てみましょう。はい、これについて抽象的な概念にまで持っていければよい訳ですね。1つの実際にする存在するモデルは、概念をそぎ落として実装されたものですから、1つだけを見ると概念モデルが不完全である可能性があります。コンテンツの実例としてアプリケーションや動画、記事などがある訳ですが、ここで既に差があります。アプリケーションには長さという概念がなく、動画、記事には価格という概念がありません。動画は無料動画とか有料ストリーミング動画とかありますから、価格という概念は出てきやすいかな、とは思いますけど一旦置いておきましょう。ここでもしアプリケーションというコンテンツを考慮せずに動画・記事という業務モデルのみで概念モデルを形成した場合は、価格という概念が抜け落ちてしまう訳です。実際は、当然概念が抜け落ちることがありますし、アナリシスパターン化するには、3回くらいはリリースしたシステムのドメインに対してではないと知見が足りなく上手くいかないと言われる所以ですね。コンテンツと言われるものを集めて、属性を集約してみましょう。こんな感じでしょうか。コンテンツに含まれる概念は不足していますが、今回の主題にしたいところではないため省略としています。今回は完全な概念モデルを作るのではなく、あくまでも導入ですのでこれくらいにしておきましょう。次はコンテンツの属性について見ていきましょう。前回の記事では「表示する端末」は厳密に記述すると「コンテンツを表示する端末・OS組合せの一覧」ですね。要はブラックリストです。掘り下げると「コンテンツ」の「表示を許可」する「端末・OS組合せ」の「一覧」ですね?ということで、ブラックリスト・ホワイトリストを図にしてみましょう。ついて掘り下げていきましょう。あるユーザが特定の端末OSでアクセスした際に表示「できる・できない」条件ですね。一般的によくあるログインユーザの所持権限によって、機能を実行「できる・できない」条件と似た構造な訳です。この権限をヒントに文脈を掘り下げましょう。あるユーザが特定の端末OSでアクセスした際に、権限が付与されていた場合に表示「できる・できない」条件ですね。この概念を元にもう少し概念モデルに近づけましょう。あるユーザが特定条件(指定端末)でアクセスした際にはコンテンツを表示する権限を有するため、コンテンツの表示が可能と。コンテンツの属性について、この表示権限と同じ概念のものを探していきましょう。プレミアム対象」「年齢レーティング」が合致しそうですね?細かく見ていきましょう。アクセス者の生年月日もしくは年齢、年齢別アクセスチェック(確認)の可ということですね。これらを踏まえてもう少しこの概念を成長させてみましょう。大まかにいくとこんな感じでしょうか。この構造によって表示権限が増えたとき、例えばコンテンツを表示するための条件としてシンジケーション(収益対象化のプラットホーム)からのアクセスのみ表示を行う、という要件が加わったときに、コンテンツ自体やその関連に変更はなく、表示権限の実装の1つとして、ユーザ・端末OS組合せと同じ階層に「ユーザのアクセス元」が基準値として加わるわけです。このシンジケーション要件例は、記事のPVを元にユーザに何かの価値(お金、ポイント等)を提供する際に、PVにはRSSで参照されたPVを表示したくないという事ですね。RSSには広告を任意に含めるのは難しいですし、ブログとしての広告媒体という意味で見られていない訳でありRSSにシンジケーションは含めない、という要件例であればこの概念ドメインにマッチすると思います。表示権限のみを掘り下げましょう。この表示権限は複数の責務を担っています。「記事」が「プレミアムユーザ対象記事(基準値の算出)」の場合、「アクセスユーザ(入力値)」が「プレミアム課金者(演算・演算方法)」でなければ記事を参照する権限を持たない訳です。概念的にいきましょう。結局のところ、ある2点間「アクセスユーザのプレミアム課金」「記事のプレミアム対象」における関係がどうなのかを演算する責務と、2点間を割り当てる責務がある訳ですね。2点間を割り当てする責務はどうなるべきでしょう。2点間を割り当てるということは、その2点が概念的に等価、等級が同一といいますか、を知っている必要がある訳ですし、同一にする責務を負っているはずです。算出は、単なるプロパティの選択ではなく、値の変換を含めた導出です。よって、「入力値の算出」「基準値の算出」はある値の導出を行うものであり、「表示権限」ではないため、導出責務として独立し、表示権限は導出責務を知るという責務だけあればよい訳ですね。例を挙げてみましょう。年齢レーティングというものがあります。R15やR18ですね。ある記事が18歳以上でなければ参照する権限がない、ということは2点は「記事に設定された年齢レーティング(から算出される実際の年齢)」と「アクセスユーザの生年月日(から算出される年齢)」になりますが、この概念的には異なる2点を同一概念に変換する必要があります。立ち戻って結局のところこの概念は「表示権限」ですから、異なる2つの概念を同一にする訳ではないですよね。3つ残っていますね?ということでそちらも探求してみましょう。カンの良い方はもう理解してそうですが、つまるところ表示の可否と演算方法はどちらも演算であって一緒ですよね。導出責務と同じく、表示権限が演算の内容を知る必要はなく、パッケージされた演算手法のみを知る責務があるわけです。結局のところ、表示権限は「導出責務」と「演算責務」の関係を作動させる責務がある、という事です。ここまでを図にしてみましょう。はい、随分簡単になりましたね。残りはもう少しです、頑張りましょう。結局表示権限となりましたが、この検索する際の条件は1つではなく複数になるはずです。「記事がプレミアム対象の際は、ユーザがプレミアム課金者」「記事が公開済である」「現在時刻が記事の公開日より未来である」等です。これについて考えてみましょう。関係した結果になりそうですね?そして、導出責務(基準値の算出)が「記事が公開済である」になり、演算責務は「論理和」になる訳です。表示権限は子要素となる表示権限を持つ場合がある、ということですね。いうことでこうなりました。次は違う例にいってみましょう。経験豊富な方ならお気づきかも知れませんが、ここで扱うのはそう、「長さ」についてです。このままドメイン設計の観点から言ってしまうと、コンテンツというドメインの概念には長さを表すValueObjectが1つあり、長さを表す。実ドメインとしての動画ドメインであれば長さというValueObjectは再生にかかる長さを表すものである。なってしまいますね?しかし待ってください、我々が本当に知りたいのは、「長さ」ではないでしょう。YouTubeで動画の長さ(再生時間)を見て「再生時間はコンテンツを消化する時間」と認識しているはずです。消化というのはつまり、参照したコンテンツからユーザが期待した結果を得られるまでの時間、ということです。例を挙げてみましょう。ブログ(記事)の長さの基準に文字数というものがあります。この記事の文字数だけ見ても参照する人にとっては何の参考にもなりませんね?そう、記事の中に動画やスライドが含まれていればその記事を読んでいる時間が延びるはずです。「平均的に参照するまでの参考値」という事ですね。その1つに文字数であったり、動画の長さがあるという事です。いうなら、単純な再生時間、つまりコンテンツを参照する最大時間も持つべきです。コンテンツは複数の長さを持つ、ということですね。ここでコンテンツは複数の長さを持つ、としてドメインの概念を理解することによって、最終的に実装される「コンテンツ」テーブルに長さを持たず、「コンテンツ長さ」テーブルという関係テーブルに長さを持つことによって、容易にコンテンツの参照の参考値となる長さを追加できる訳です。例に挙げたコンテンツと表示権限と長さの概念が全てに当てはまるかというときっと知見が足りません。世には色々なデジタルコンテンツのサービスがありますから、もっと素晴らしい概念が含まれているかも知れません。毎回このドメインの概念を探求していくべきですし、ドメインが進化していく以上完成はないわけです。ここで用いたアナリシスパターンでブログシステムを構築した後に、動画配信サービスを構築する際はドメインモデルのスタートとしてきっと役に立つと思いますし、真っ新からスタートした状態よりは堅牢なドメインモデルを作りやすいはずです。いうことで、このドメインへの探求(の入り口)への手助けになれば、と思います。時間に余裕ができたら実装編ということでコンテンツ管理(4)に続きます。(3)Tweet広告を非表示にする関連記事2016-04-04転職活動日記(1)はい、今回は転職活動についての雑記です。(2)前回の記事はこちら(リンク先)からどうぞ。(1)ドメイン駆動やドメイン駆動設計が世に広まって久しいですね。(2)はてなブログをはじめよう!geaneさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。