速さが足りないスマートフォン用の表示で見る速さが足りないプログラミングとか、設計とか、ゲームとかいろいろ雑記。この広告は、90日以上更新していないブログに表示しています。(1)ドメイン駆動ドメイン駆動やドメイン駆動設計が世に広まって久しいですね。bootstrapみたいな形で実装してく等の技術的な要素は勿論重要ですが、ドメイン設計と言いますか、分析モデルを作り上げていきドメイン設計として実装まで至る方もとても重要だと思います。分析モデルからドメイン設計に至るまでは、業務ロジックと言いますか、ビジネスのコアな部分であることが多いため世に記事として出ない事が多いせいでしょうか、あまり注力というか注目というかされてない気がします。パフォーマンスを始めとする非機能要件も勿論重要ですけどね。いうことで今回のお題は「コンテンツ管理・配信」です。初回の当記事は開発フローの知識というか前提条件を統一するために、一般的な開発を例に挙げましょう。それでは張り切っていってみましょう。様々なコンテンツをアップロードおよび配信するコンテンツ管理・配信システムを作りたい、という要求から始めることにしましょう。業務分析や要求定義で使うユースケースやアクティビティ図がありますね?ということで、ユースケース図を用意しました。今回はさくっと書いてますが、もっとたくさんのユースケースがありますし、図中のアクターやユースケースももっとたくさん出てくるはずです。はい、次はアクティビティ図です。はい、記事投稿機能についてのアクティビティ図です。注釈があったりしますが、まぁ置いておきましょう。これらの業務分析や要求定義の結果、以下のような要求仕様ができあがるわけですね。してはざっくりこんなかんじですかね。実際は各項目にもっと細かい要求の説明があると思いますし、項目自体ももっと多いはずです。いうことで、次は非機能要件に行きましょう。(システム効率)、時間効率性(業務効率)、資源効率性はい、かなり略しましたが非機能要件です。これらももっと項目がありますし、各項目についての要求が述べられる訳ですね。障害許容性は3営業日以内に復旧すればいいよ、みたいな業務システムの場合(あるのかそんなシステム?っていうツッコミは置いておいて)、パフォーマンス的な観点で見て通常のマシンスペック(もしくはスケールアップしたもの)でスループットを達成できればシステムを冗長化する必要はない訳ですね。今回は関係なさそうに見えますが、効率性という非機能要件においては、分析モデルからドメイン設計する際に影響を受ける可能性があるかも知れません。上記の非機能要件については日本情報システムユーザー協会(JUAS)が発行したガイドライン(リンク)を使っていますので、興味がある方はリンク先を参照ください。次は業務フローと運用フローにいきましょう。基本はアクティビティ図みたいなものが複数出来上がると思いますので、イメージは省略します。B2Cのシステムであれば、問合せ機能が要求にあり、電話もしくはメールでの問合せが主となると思いますが、そういった運用フローも含まれている訳ですね。実際は存在しないプロジェクトの方が多かったりしますが・・・。いった情報を元にサブシステムとしての管理システム(の要求)にユーザのタイプ(administrator、operator等)を持つ必要があるか?等の検討が進むわけです。業務モデルが出てくるのは次のステージの方が多いとは思いますが、良いプロジェクトであればステークホルダーやコンサルタントが自前で持ちだしてくる事もありますし、今の段階で描いてみましょう。はい、こんな感じですね。実際はもうちょっとドメインがあったりしますが、今回はそういったものを想定できる細かい要求仕様がないので省略しています。ドメインに対するプロパティの型を今この段階で明示する必要はないんですが、この図を書いているツールのクラス図がそうなってますので、図のサンプルとして入っちゃってます。大まかに情報が出そろったところで、今回はこういう環境構成で、こういうシステム関連図で、っていうのができてきますね?ということで単純な環境構成で書いてみました。scalingかbeanstalkにしたり、RDSはauroraにする、各サーバを冗長化する等色々ありますし、オンプレの場合もありますし、セキュリティ要件や想定ユーザ数、スループット等に影響されますので今回のはあくまでイメージということで。システム関連図は本来あった方がいいと思いますが、今回は通りAndroid/iOSであればネイティブアプリからAPI経由で閲覧・登録し、ウェブ版であればWeb→APIで登録とぱっと見て分かると思いますので省略とします。その次に参りましょう。ここで各機能別に画面遷移図や画面定義書が出来上がり、データベース設計書なんかができてくる訳ですね。画面遷移図や画面定義書はあまり関係ないので省略するとして、データベース定義(ER図)はこんなかんじでしょうか。分析モデルをそのままデータベースにすることが多いですし、そのままにしてみました。良し悪しで言うと当然ダメですがまずは先に進みましょう。今後、サーバ側のドメインについて言及することが多いと思いますので、ここでAPIのインターフェースを定義してみましょう。ブログにおける記事を参照するとき、一覧と詳細の表示があると思いますのでこの2つにしましょう。一般にブログを見る時は全件or月別アーカイブorタグのどれかですので、その3つを検索条件として一覧を返すAPIと、記事自体を一意に識別するユニークキーを渡すと詳細を返すAPIって感じですね。detail:'<p>ドメイン駆動やドメイン駆動設計が世に広まって久しいですね。上記のように今までの検討結果を持ってプログラミングが始まり、テストしてテストして・・・最後にリリースして、また最初のサイクルに戻る訳ですね。ご存知のサイクルですね。いや知ってるし別に・・・って方は長々やってしまってすいません。あとは、設計書を増やしたり減らしたり、最初にテストコード書いたり、もっと(大きい/小さい)機能別にライフサイクルを回したり、それらの複合でやったり・・・と色々なやり方はありますよね。分析モデルもドメイン駆動もプロジェクト運営手法も、今回は出てきてない継続インテグレーションも、変更を最小にし、変更が容易で柔軟なシステムを作る事が目的の一つで、様々な手法のどちらか一方しか選択できないという訳ではないので、全部いいとこどりすればいいじゃないという事で置いておきましょう。まあ実際は全部やるのはコストとスケジュールの都合で難しいとは思いますけどね。前置きがとても長くなりましたね。次回はこのシステムに対する変更を見ていきましょう。(1)Tweet広告を非表示にする関連記事2016-04-04転職活動日記(1)はい、今回は転職活動についての雑記です。(3)前回の記事はこちら(リンク先)からどうぞ。(2)前回の記事はこちら(リンク先)からどうぞ。Reflection(メソッドを呼び出す)前回の記事はこちら。今回はメソッドの呼び出しです。(2)はてなブログをはじめよう!geaneさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。