現場で役に立つシステム設計の原則の感想

2017 年の反省、2018 年の目標で掲げた今月の目標の、現場で役立つシステム設計の原則を読んで感想をブログに書く。

感想

とても読みやすく、設計の参考になる内容だった。オブジェクト指向をなんとなく分かっていて実践しているつもりだったが、全然できていなかったことを教えてくれた。特に前半の部分はすぐに実践できる部分が多く、仕事に活かしていきたい。
後半は、データベースや画面などのドメインモデルの外側に業務ロジックが漏れ出ないようにする一例として参考になった。
また、紹介されている書籍でさらにオブジェクト指向を深く学んで、さらに設計を洗練できるようにしたい。
数年前に読んだドメイン駆動設計を今読み直せば、色んな発見がありそうだ。

第 1 章 小さくまとめてわかりやすくする

どこに何が書いてあるのかわかりやすくして、修正を楽に安全にするためにコードを整理するテクニックが紹介されていた。
まず、基本としてクラス名や変数名にわかりやすい名前をつけること。
また、汎用的なプリミティブ型ではなく専用のクラスを用意すること。例えば金額や電話番号を int や String ではなく、Amount、Telephone という専用のクラスを用意することで、利用できる値の範囲を制限したり、関連する処理をそのクラスに集約でき、重複するコードを減らすことができる。
同じように配列やコレクションクラスも専用のクラスを用意して、集計、要素数の制限、ゼロ件の場合などの処理も集約できる。

第 2 章 場合分けのロジックを整理する

プログラムを複雑にする場合分けを減らすテクニックも紹介されていた。
条件とロジックを独立させて、その組み合わせをクラスにまとめ、それぞれのクラスを多態で処理すること。
そうすることで、if 文や switch 文を減らすことができる。

第 3 章 業務ロジックをわかりやすく整理する

プログラムの修正を難しくさせる原因として、データクラスとロジックを記述する機能クラスが分かれていることが挙げられていた。
これは、データクラスを参照できるところであれば、そのクラスを処理できてしまうということ。つまり、プログラムを修正するときにはまずそのデータクラスを処理している場所を全て特定し、全ての処理が問題ないように修正しなければならなくなる。
それを回避するために、データとロジックをクラスにまとめること。
ロジックはそのクラスにまとまっているので修正範囲を狭めることができる。

第 4 章 ドメインモデルの考え方で設計する

この章でドメインモデルとデータモデルの違いを理解できた。
ドメインモデルの設計の狙いは、業務ロジックの重複をなくし、業務とプログラムを一致させてどこに何が書いてあるのか整理し、業務ルールの変更や追加のときにプログラムの変更の影響範囲を狭めることにある。
年齢を例にすると、ドメインモデルではまず年齢クラスを作り、そのクラスには生年月日から年齢を計算したり、子供なのか大人なのか判断するロジックが集まる。一方データモデルでは、生年月日だけを記録する。年齢は生年月日から計算された結果なので記録すべき対象とはならない。また、年齢を求めるロジックはどこでも書けるので重複が発生しやすくなる。

また、ヒト/モノ/コトで業務の関心事を分類すると、ドメインモデルの設計に必要なドメインオブジェクトを見つけやすくなる。
ヒトというのは個人や企業、担当者など、意思、判断、行動についてのデータを持ち、そのデータを使った判断、加工、計算のロジックを持っている。
モノといのは数量や金額、説明、状態などを表現し、それらの判断や加工、計算をするロジックを持っている。
コトはいつ、何に、何の事象が起きたのかを表す。販売管理システムでいえば、受注、出荷、請求、入金がこれにあたる。
特にコトはヒトとモノとの関係で出現するので整理しやすくなる。

第 5 章 アプリケーション機能を組み立てる

ドメインモデルを使って、必要な機能を実現するアプリケーション層の説明がされていた。
画面をプレゼンテーション層、進行役をアプリケーション層、記録と通知の仕組みをデータソース層とし、ドメインモデルはアプリケーション層が扱うもの。
アプリケーション層のクラスをサービスクラスといい、プレゼンテーション層が要求するドメインオブジェクトを返したり登録のみの処理にする。
ここに業務ロジックを書いてしまうと重複が始まってしまうので、あくまで業務ロジックはドメインモデルに書くこと。
サービスクラスをシンプルに保つことで部品として扱えるようにし、組み合わせたシナリオクラスを使って複雑な要求に応えられるようにすること。
登録する処理はデータベースの操作を意識しないこと。例えば銀行口座のサービスクラスなら、金額の取得や登録、更新ではなく残高照会、引き出し、振り込みというように業務に適したクラスにする。

第 6 章 データベースの設計とドメインオブジェクト

どのようなデータが入っているかわからない、データのないカラムが多い、データが重複していてどれが正しいかわからないなど、テーブル設計の悪さをプログラムで吸収すると、プログラムが複雑になってしまう原因になる。それを回避するために、データベースのテーブル設計が重要になってくる。
適切なデータ型を利用し、NOT NULL 制約で正規化、一意性制約でデータの重複を防ぎ、、外部キー制約でテーブル間の関係を明確にすることで、プログラム側でデータの処理を吸収しなくて済むようにできる。

第 7 章 画面とドメインオブジェクトの設計を連動させる

利用者にとって画面こそがソフトウェアの実体だが、画面は様々な関心事が複合していて、単純にドメインオブジェクトと連動させることは難しい。利用者がこの画面にこの機能がほしいと要望を出しても、開発者はどのドメインモデルが必要なのか、どこを修正すればいいのか検討しなければならなくなる。
そこで、画面とドメインオブジェクトの設計を連動させるために以下のことを行う。
ドメインオブジェクトと一致していない場合はドメインオブジェクトで提供できる情報の設計を改善するか、ドメインオブジェクトを画面のデザインに反映させること。
物理的なビューと論理的なビューを区別し、論理的なビューはドメインオブジェクトが表現すること。
表示項目とドメインオブジェクトのフィールドの並び順、表示項目のグルーピングとドメインオブジェクトの単位は一致した設計にすべき。
リリースノート、利用者ガイド、ドメインオブジェクトの情報が整合していること。
このように画面とドメインオブジェクトの設計が連動していると、開発者は利用者の関心事を理解しやすくなり、修正や拡張が容易になる。

第 8 章 アプリケーション間の連携

連携方式はファイル転送、データベース共有、Web API、非同期メッセージングがある。
ファイル転送は実装は簡単だが、機能や性能に制約が生まれがち。
逆に非同期メッセージングは自由に実装できるが、設計や運用が難しくなる。
肥大化した Web API は使う側も提供する側も負担が大きい。
複雑なレスポンスは JSON より XML の方が適している場合もある。

第 9 章 オブジェクト指向の開発プロセス

マネジメントの観点からオブジェクト指向で開発するための考え方も紹介されていた。
要件定義、基本設計、詳細設計、実装、単体テスト、システムテスト、受入テストの V 字モデルは変わらないが、フェーズではなく作業単位で行う。
分析と設計を同じ人が担当する。
ソースコードやテストコード、ビルドスクリプトなどがドキュメントを担うことで、ドキュメントを減らす。ただし、それが決定された理由などはドキュメントとして残した方が他の作業者の助けになると思われる。(議事録など)
進捗の判断は、初期の段階ではドメインモデルの充実やテストコードが指標となる。画面が動くようになればそれで測定できる。

第 10 章 オブジェクト指向の学び方と教え方

オブジェクト指向はチーム共通で開発するため、メンバー全員で理解できる必要がある。
そのための学習方法が説明されていた。
オブジェクト指向は言葉の説明より具体的なコードで学ぶ方が実践的。
書籍『リファクタリング』を参考に既存のコードを改善してみる。
書籍『ThoughtWorks アンソロジー』のオブジェクト指向エクササイズで練習してみる。
書籍『実装パターン』『オブジェクト指向入門 原則・コンセプトオブジェクト指向入門 方法論・実践』『ドメイン駆動設計』でより深く学ぶ。

Note, Programming

1 comment


  1. Pingback: 2018 年 1 月の振り返り | I Wanna Be β

コメントを残す

メールアドレスが公開されることはありません。