現場で役立つシステム設計の原則 ch7 画面とドメインオブジェクトの設計を連動させる
まとめ
- 利用者の関心事とプログラムの表現を一致させる
- そのためのOOP
画面アプリケーションの開発の難しさ
画面にはさまざまな利用者の関心事が詰め込まれる
- 利用者にとっては画面こそがソフトウェアの実体
- 要望のヒアリング等に画面のプロトタイプは有用
- 要望を取り入れていくと複雑になりがち
画面に引きずられた設計はソフトウェアの変更を大変にする
- 画面単位のプログラムの難点
- 表示のためのロジックと業務ロジックが混在してしまう
- 例: 強調表示の条件は業務ロジック
- 複数の画面に同じコードが重複してしまう
- 同じ関心事を扱っている複数の画面に散らばる
- 表示のためのロジックと業務ロジックが混在してしまう
関心事を分けて整理する
- 画面を分け、何でもできる汎用画面を避ける
- 画面の表示ロジックと業務ロジックを分ける
画面の関心事を小さく分けて独立させる
複雑な画面は異なる関心事が混ざっている
- 例
- 注文者を特定する情報
- 注文した商品と個数
- 決済方法
- 配送手段と配送先
- 連絡方法
小さな単位に分けて考える
- 各関心事に対応するドメインオブジェクトを作る
- 組み合わせて注文クラスを作る
画面も分けてしまう/タスクベースに分ける設計が今後の主流
- タスクベースのユーザインタフェース
タスクベースのインタフェースが増えている2つの理由
- SPの利用の拡大
- たくさんの情報を入力するのがつらい
- 通信環境の変化
- 小さな単位の頻繁な通信が普通になった
画面とドメインオブジェクトを連動させる
画面もドメインオブジェクトも利用者の関心事のかたまり
ドメインオブジェクトと画面の食い違いは設計改善の手がかり
画面の関心事とドメインオブジェクトの粒度や構造と整合しにくいことがある
- タスクベースのユーザインタフェースの場合
- ドメインオブジェクトか画面いずれかの設計の改善の余地あり
- 「何でも画面」の場合
ドメインオブジェクトに書くべきロジック
論理的な情報構造
- 論理的な情報構造は含める
- 要約文の加工ロジック(20文字切り出す、とか)
- 「複数の段落」という構造をコレクションで保持
- 用語と定義のペアをMapで保持
- 物理的な表示方法は含めない
<p>タグ- 改行コード
場合ごとの表示の違い
- 画面表示でif文を使っている場合は、その条件判断をドメインオブジェクトに移動することを検討
- 「N件見つかりました」「見つかりませんでした」等の文字列ごと
- ビューとモデルとの分離に違反するのでは？
- このほうが変更容易
- 文字列表現は利用者の関心事そのものなので、むしろ自然
- cf. 物理的な表示方法である改行コードやHTMLタグは含めない
- ビューとモデルとの分離に違反するのでは？
- 【所感】それはドメインロジックではなく、アプリケーション固有のロジックなのでは…？
HTMLのclass属性をドメインオブジェクトから出力する
他
- カンマ編集、1000円単位表示等
- 【所感】これもアプリケーション固有のロジックなのでは…？
画面(視覚表現)とソフトウェア(論理構造)を関係づける
項目の並び順とドメインオブジェクトのフィールドの並び順
- 不一致すなわち、ドメインオブジェクトが利用者の関心事を適切に表現できていない可能性
- クラスのメンバの定義順等も画面上の表示順に合わせる
画面項目のグルーピング
- 画面デザインの4原則
- 近接
- 整列
- 対比
- 反復
- これらを丁寧に実践している画面はドメインオブジェクト設計のよい手がかり
画面のデザインとソフトウェアの設計を連動させながら洗練させていく
- 画面がタスクベースならば、画面にドメインオブジェクトを寄せやすい
- cf. 「何でも画面」ならば、ドメインオブジェクトの設計駆動で、画面をより論理的にデザインする改善点を提供すべき
- 利用者/画面のデザイナ/ソフトウェア開発者が一緒になって検討する
画面以外の利用者向けの情報もソフトウェアと整合させる
- 利用者の関心事とソフトウェアの設計のねじれを放置しない
- 利用者が触れられるもの、開発者以外が確認できるもの、開発者にしか見えないものの整合性を保つ
- プレスリリースに記載したセールスポイント
- リリースノートでの新機能の概要説明
- 利用者ガイドへの新機能の説明の追加
- ドメインオブジェクトの追加
