skillup

技術ブログ

アーキテクト設計全般

オブジェクト指向 プレゼンテーション層

投稿日:2017年7月27日 更新日:

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。

本日はプレゼンテーション層、いわゆるMVCのViewにあたる部分。

プレゼンテーション層の考え方

要点

  • 画面ごとにプログラムを組むのではなく、関心ごとでプログラムを組む。そうしないと複数の画面でコードが重複する
  • 例えば詳細画面と登録確認画面は表示するデータの形式は一緒なことが多い。画面は違ってもプログラムは一緒
  • 関心ごとにより分け、画面の表示ロジックと業務ロジックを分離させる
  • 画面自体も機能ごとにわけ、あれもこれも詰め込まない(ECなら顧客氏名、注文内容、決済方法、配送手段、連絡先、注文確定などは分ける)
  • 画面の項目ごとに関心ごとをグルーピングする、あるいは画面自体を別にする。複数ステップ画面(タスクベースのユーザーインターフェイス)。1ページ、1メッセージ(プレゼント一緒!)
  • 画面とドメインオブジェクトが対応していないときは、ドメインオブジェクトの設計を見直す絶好のチャンス(関心ごとになっているのか?)。画面とドメインオブジェクトは利用者の関心ごとが一致するはず
  • 画面側のif文の分岐やcssの変更などもドメインオブジェクトの中に格納する。なぜならそれは関心ごとという枠組みだから。こうすることによりドメインオブジェクトだけを変更対象にすればOK。
  • 画面項目のグルーピング
    近接・・距離の近さは情報の近さ
    整理・・同じ意味のものは同じラインに。
    対比・・意味の重みの違いは文字の大きさや色の違いで区別
    反復・・同じ意味のものは同じパターンで

感想

画面項目を情報の意味でグルーピングするというのは、いろんな本でも書かれていたけど、基本ですね。今の業務アプリも特に注文画面にいろんな情報が詰め込まれており、あれもこれもになってしまっている。

というかデザインだけに限らずあらゆる領域で必要になってくる考え方だと思います。画面の分岐による変更ロジックをドメインオブジェクトの中に組み込む、というのは驚き(本書の中でもかかれていますが・・・)。ようはドメインオブジェクト=関心ごとなのだから、すべてドメインオブジェクトの中に入ってくるだろうということらしいんですね。

 

 

-アーキテクト設計全般

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

アプリケーションアーキテクチャについて 〜ドメインモデルに関して〜

前回のトランザクションスクリプトパターンの反省から 今回はいわゆるドメインモデルの具体例に関して。 ドメイン駆動型設計には以下のような特徴があります。 大きく、アプリケーションの構成を以下のように分け …

no image

アプリケーション間のデータの連携方法に関して

以前やった「現場で役立つシステム設計の原則」を再読してます。 今、読んでいるのはアプリ間のデータ連携に関して。 複数のアプリ間でデータをやり取りする場合、以下のような方法が考えられます。 ファイルを直 …

no image

オブジェクト指向について その3

今回は場合分けによる変更コストとオブジェクト指向のメリットについてです。 例えば給付金が発生して、その金額を死亡時、退職時、通常時で場合分けするとき、if-elseで書けば下記のようになります。 [c …

no image

APIに関して

RESTAPIのルーティングで気をつけることなんぞを。 直近のプロジェクトではRESTAPIを作ることが多かったんですが気をつけることなんぞを。 Contents1 仕様書はソースから2 ツール3 命 …

no image

クリーンアーキテクチャーがらみの話題など

クリーンアーキテクチャに関してメモ。 自分がプログラミングを学習したのは10年ほど前ですが、当時はいわゆるMVC(Model – Controller – View)でアプリケ …

アーカイブ