速さが足りない

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

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

ドメイン駆動やドメイン駆動設計が世に広まって久しいですね。
個人的には、最新技術、例えばインフラはAWS(elastic beanstalk + aurora DB)の、アプリケーションはscala + play2 + aurelia + bootstrapみたいな形で実装してく等の技術的な要素は勿論重要ですが、ドメイン設計と言いますか、分析モデルを作り上げていきドメイン設計として実装まで至る方もとても重要だと思います。


分析モデルからドメイン設計に至るまでは、業務ロジックと言いますか、ビジネスのコアな部分であることが多いため世に記事として出ない事が多いせいでしょうか、あまり注力というか注目というかされてない気がします。
まあ、パフォーマンスを始めとする非機能要件も勿論重要ですけどね。

ということで今回のお題は「コンテンツ管理・配信」です。
初回の当記事は開発フローの知識というか前提条件を統一するために、一般的な開発を例に挙げましょう。

それでは張り切っていってみましょう。



さて、スタートは自作アプリケーションや写真・動画・記事等の様々なコンテンツをアップロードおよび配信するコンテンツ管理・配信システムを作りたい、という要求から始めることにしましょう。
まずは業務分析や要求定義で使うユースケースやアクティビティ図がありますね?
ということで、ユースケース図を用意しました。
今回はさくっと書いてますが、もっとたくさんのユースケースがありますし、図中のアクターやユースケースももっとたくさん出てくるはずです。

f:id:geane:20160301220611p:plain



はい、次はアクティビティ図です。

f:id:geane:20160301220612p:plain

はい、記事投稿機能についてのアクティビティ図です。もう少し注釈があったりしますが、まぁ置いておきましょう。
これらの業務分析や要求定義の結果、以下のような要求仕様ができあがるわけですね。

  • ブログ機能
    • 記事の登録・編集
      • htmlにて編集・配信できる機能
      • 太文字・斜体・打消し・アンダーライン等文字を整形する機能
      • 見出し・タイトル・引用符・リンク・表示の開閉・箇条書き・注釈等の記事を整形する機能
      • 色編集機能
      • 編集中のhtmlをプレビューする機能
      • 配信URL編集機能
      • 配信日時指定機能
      • タグ設定機能
        • タグ一覧表示・登録・編集・削除機能
      • 下書き保存機能
      • プレミアムユーザ向け記事設定機能
      • 年齢によるレーティング制限機能
    • 記事一覧機能
    • 記事削除機能
    • 記事評価・コメント機能
    • ブログ概要登録・表示機能
      • 説明文
      • オーナー情報
      • オーナー情報(外部URL)
      • 投稿数
      • 継続日数
      • カテゴリ
    • レイアウト編集機能
      • タグ一覧表示機能
      • 配信月一覧表示機能
      • テンプレートによるレイアウト編集
      • 手動によるレイアウト編集
    • ブログ内検索機能
  • ユーザ管理
    • ユーザ一覧表示・登録・編集・削除機能
    • ログイン機能
    • ユーザランク(プレミアム登録)機能
  • アプリケーション配信・管理
    • アプリケーション一覧表示・登録・編集・削除機能
    • アプリケーションの評価・コメント機能
    • アプリケーション配信予約機能
    • 指定端末のみ配信可能な機能
      • 端末一覧表示・登録・編集・削除機能
    • タグ一覧表示・登録・編集・削除機能

要求仕様としてはざっくりこんなかんじですかね。実際は各項目にもっと細かい要求の説明があると思いますし、項目自体ももっと多いはずです。




ということで、次は非機能要件に行きましょう。今回はざっくり書いちゃいますね。

  • 機能性
    • 正確性、合目的性、相互運用性、セキュリティ、機能性標準適合性
  • 信頼性
    • 成熟性、障害許容性、回復性、信頼性標準適合性
  • 効率性
    • 時間効率性(システム効率)、時間効率性(業務効率)、資源効率性

はい、かなり略しましたが非機能要件です。これらももっと項目がありますし、各項目についての要求が述べられる訳ですね。
例えば障害許容性は3営業日以内に復旧すればいいよ、みたいな業務システムの場合(あるのかそんなシステム?っていうツッコミは置いておいて)、パフォーマンス的な観点で見て通常のマシンスペック(もしくはスケールアップしたもの)でスループットを達成できればシステムを冗長化する必要はない訳ですね。
今回は関係なさそうに見えますが、効率性という非機能要件においては、分析モデルからドメイン設計する際に影響を受ける可能性があるかも知れません。


なお、上記の非機能要件については日本情報システムユーザー協会(JUAS)が発行したガイドライン(リンク)を使っていますので、興味がある方はリンク先を参照ください。


次は業務フローと運用フローにいきましょう。
基本はアクティビティ図みたいなものが複数出来上がると思いますので、イメージは省略します。
例えばB2Cのシステムであれば、問合せ機能が要求にあり、電話もしくはメールでの問合せが主となると思いますが、そういった運用フローも含まれている訳ですね。実際は存在しないプロジェクトの方が多かったりしますが・・・。
まあ、そういった情報を元にサブシステムとしての管理システム(の要求)にユーザのタイプ(administrator、operator等)を持つ必要があるか?等の検討が進むわけです。
さて、業務モデルが出てくるのは次のステージの方が多いとは思いますが、良いプロジェクトであればステークホルダーコンサルタントが自前で持ちだしてくる事もありますし、今の段階で描いてみましょう。

f:id:geane:20160304162404p:plain

はい、こんな感じですね。
実際はもうちょっとドメインがあったりしますが、今回はそういったものを想定できる細かい要求仕様がないので省略しています。
なお、ドメインに対するプロパティの型を今この段階で明示する必要はないんですが、この図を書いているツールのクラス図がそうなってますので、図のサンプルとして入っちゃってます。


どんどん行きましょう。
大まかに情報が出そろったところで、今回はこういう環境構成で、こういうシステム関連図で、っていうのができてきますね?
ということで単純な環境構成で書いてみました。

f:id:geane:20160304170819p:plain


実際はAWSであればEC2をauto scalingかbeanstalkにしたり、RDSはauroraにする、各サーバを冗長化する等色々ありますし、オンプレの場合もありますし、セキュリティ要件や想定ユーザ数、スループット等に影響されますので今回のはあくまでイメージということで。
システム関連図は本来あった方がいいと思いますが、今回は通りAndroid/iOSであればネイティブアプリからAPI経由で閲覧・登録し、ウェブ版であればWeb→APIで登録とぱっと見て分かると思いますので省略とします。


その次に参りましょう。ここで各機能別に画面遷移図や画面定義書が出来上がり、データベース設計書なんかができてくる訳ですね。
画面遷移図や画面定義書はあまり関係ないので省略するとして、データベース定義(ER図)はこんなかんじでしょうか。

f:id:geane:20160304182141p:plain

まあ分析モデルをそのままデータベースにすることが多いですし、そのままにしてみました。
良し悪しで言うと当然ダメですがまずは先に進みましょう。
今後、サーバ側のドメインについて言及することが多いと思いますので、ここでAPIのインターフェースを定義してみましょう。
ブログにおける記事を参照するとき、一覧と詳細の表示があると思いますのでこの2つにしましょう。
一般にブログを見る時は全件or月別アーカイブorタグのどれかですので、その3つを検索条件として一覧を返すAPIと、記事自体を一意に識別するユニークキーを渡すと詳細を返すAPIって感じですね。

API URL 入力パラメータ 出力内容(サンプル)
記事一覧取得API date:yyyyMMで指定すること
tagId:検索するタグのID
blogId:検索するブログのID
https://api.cms.companyname.co.jp/api/1.0.0/blog/article/?date=201601&tagId=123456&blogId=88877766 ※1
記事詳細取得API 省略 省略 省略

※1

{
  articles:[
    articleId:2222345676,
    blogId:123456,
    ageRating:12,
    title:'ドメイン駆動 - コンテンツ管理 (1)',
    detail:'<p>ドメイン駆動やドメイン駆動設計が世に広まって久しいですね。
個人的には、最新技術、例えばインフラはAWS(elastic beanstalk + aurora DB)の、アプリケーションはscala + play2 + aurelia + bootstrapみたいな形で実装してく...(省略)
    ',
    url:'http://www.copanynameblog.co.jp/blog/entry/20160301235959',
    isPremium:0,
    ...(以下省略)
  ],
  blogId:123456,
  paging:{
    start:0,
    end:0,
    all:2
  }
}


戻りましょう。上記のように今までの検討結果を持ってプログラミングが始まり、テストしてテストして・・・最後にリリースして、また最初のサイクルに戻る訳ですね。
まあご存知のサイクルですね。いや知ってるし別に・・・って方は長々やってしまってすいません。

あとは、設計書を増やしたり減らしたり、最初にテストコード書いたり、もっと(大きい/小さい)機能別にライフサイクルを回したり、それらの複合でやったり・・・と色々なやり方はありますよね。
分析モデルもドメイン駆動もプロジェクト運営手法も、今回は出てきてない継続インテグレーションも、変更を最小にし、変更が容易で柔軟なシステムを作る事が目的の一つで、様々な手法のどちらか一方しか選択できないという訳ではないので、全部いいとこどりすればいいじゃないという事で置いておきましょう。
まあ実際は全部やるのはコストとスケジュールの都合で難しいとは思いますけどね。





さて、前置きがとても長くなりましたね。次回はこのシステムに対する変更を見ていきましょう。