現場で役立つシステム設計の原則
現場で役立つシステム設計の原則｜Amazon
現場で役立つシステム設計の原則｜技術評論社
軽い気持ちで買った本だったけど、思った以上に良かった。
第1章と第2章は、プログラミングのテクニックに関する内容。
- 値オブジェクト
- コレクションオブジェクト
- 区分をEnum型で表現する
第3章と第4章は、ドメインモデルの説明と構築方法。
- データクラスと機能クラスを分けると変更が大変になる
- 業務ロジックを整理し、ドメインモデルを作る
- 業務の関心ごとをヒト・モノ・コトで整理する
- 業務知識をプログラムで表現したドメインモデルを作ると、業務ロジックが集約され、変更が容易となる
第5章からは、DB設計や画面設計、開発プロセスに関する内容が続く。
第9章の開発プロセスに関する内容が面白かった。
ソフトウェア全体をわかりすい構造で整理 する基本は、複雑な業務ロジックをドメインモデルに集約し、整理することです。そのためには、業務を理解し整理するための「分析」と、ソフトウェアとしての実現方法を考える「設計」を、同じ人間／チームが一貫して担当することが効果的です。
前から自分も感じていたことで、業務分析・設計・実装を同じ人が担当する方が良いものができる。何故ならば、上流工程の知識をそのままプログラムに落とし込めるから。自分が関係したプロジェクトでは、設計者と実装者が違うことによって、業務知識のない実装者がバグを作り込んでいた。品質に大きく影響するのだと実感した。
分析と設計を一 体で進めるオブジェクト指向の開発スタイルでは、このドキュメントを作成するための調査や分析作業は、ドメインモデルを設計し実装するチームが担当します。 同じチームが担当するので、大量にドキュメントを作ってから、それをプログラミング言語で書き換えていく作業はムダです。分析しながら理解した内容を、直接ソースコードとして記録し、確認していくほうが効率的です。そして、業務を理解している人間が直接プログラムを書いているのですから、要求の取り違えや抜け漏れが起きにくくなります。
ドキュメントを作ることは知識を書き出すことで、どちらかというと良いことだと思っていた。ここではハッキリとムダと書いていて、良い意味での驚きがあった。
ソースコードが分かりやすく書いているならば、ソースコードを読めば良い。それがドキュメントだと言い切ることができる。確かに・・！
システムの基本的な目的や、方向性を関係者で共有することも大切です。しかし、これはソースコードだけでは共有しにくい内容です。 基本目的や方向性を共有するための情報として次のものがあります。 ・システム企画書やプロジェクト計画書のシステム概要説明 ・プレスリリース ・リリースノート ・利用者ガイドの導入部 ・営業ツールのキャッチフレーズ これらの情報は、頻繁に更新されることはありません。しかし、重要な点を要約した貴重な情報です
必要なドキュメントもあるという点も記述されている。
この本は、ドメインモデルの解説書だと思って読んだ方が良い。参考書籍も載っていて、他の本でも勉強しようという気になった。新しく出たドメインモデルの本も読んでみようと思う。
しかし、やや疑問に感じる記述もあった。DB設計に関する章では、「テーブルにカラムを追加したい時は別テーブルにする。」と書いてあった。過去データに対しては新しいカラムにデータを入れられない、虚偽の値を入れるぐらいならば分けた方が良い、という考えである。
システム改修によってテーブルが大量に作られたシステムは、分かりやすいシステムと言えるだろうか。長期間、システムの運用保守をすることを考えると、データモデルとしてあるべき姿を作っていくべきだと考える。過去データに正しい値を入れて、カラム追加も十分にあり得る選択肢だと思った。
やや極端な考えもあるが、全体として良い本だと思った。
売り上げランキング: 3,809