「現場で役立つシステム設計の原則」はプログラミング設計の普遍的な教科書

日本のDDD（ドメイン駆動設計）界の父ともいえる増田亨さんが著した「現場で役立つシステム設計の原則」を頂いたので、早速拝読させていただきました。

本書をおすすめしたい人

本書は、システム開発で以下のような問題を抱えている人におすすめです。

• 既存システムのソースコードの可読性が低く、理解に時間がかかる
• 機能追加・改修時の影響範囲調査に時間がかかる
• 機能追加・改修時の工数が予想以上にかかる
• テストコードが書きにくいソースコードになりがち
• 機能を追加・改修時の影響範囲が大きくなりがちで、テスト工数がかさんでいる
• デグレの確認に気を使い、多くの時間をかけている
• 不具合が発生したときに、調査・解決に時間がかかってしまう
• 新しいメンバーがプロジェクトに参画した時に、業務知識を伝えるのに多くの手間がかかる
• これらの問題のために、生み出す価値以上に、仕事時間が増えている

このような問題を解消し、変更に強いソフトウェア開発をするために、著者の増田氏が説明しているのが、ドメインモデル駆動設計によるオブジェクト指向プログラミング（以下、オブジェクト指向プログラミング）です。

オブジェクト指向プログラミングのメリット

従来からの手続き型プログラミングとオブジェクト指向プログラミングは、何が違うのかという方もいらっしゃると思います。

その違いが分かるように書籍の全体像を、私なりにまとめてみました。

以下の図は、書籍第3章に掲載されている図です(P.90 図3-4）。

シンプルな図ですが、この図を理解することが、オブジェクト指向プログラミングの全体像を理解することになるでしょう。

さらに説明を加えたのが以下の図です。

オブジェクト指向プログラミングは、現実世界を抽象化し、ソースコードで表現します。

本書では「関心事」という重要なキーワードが数多く登場しますが、「関心事」とは、ソースコードで記述しようとする対象のことです。

ドメインモデルの関心事は、現実世界の業務です。

ドメインオブジェクトには、カプセル化（情報隠蔽）*1の考え方をもとに、現実世界の業務データ、業務ロジックを記述します。そして、オブジェクト同士の相互作用として、ドメインオブジェクト同士のメソッド呼び出しを記述します。

そのとき、技術環境、たとえばWebアプリ、スマートフォンアプリなどのアプリの種類や、実装技術（アプリケーションフレームワーク、データベース、HTML5など）は、ドメインモデルの関心事ではありません。

一方、3層（プレゼンテーション層、アプリケーション層、データソース層）の関心事は、実装技術の操作です。

ドメインモデルとは逆に、3層には実装技術に関係するコードを記述し、現実世界の業務に関するロジックは書かないようにします。

このように、オブジェクト指向プログラミングでは、オブジェクト指向プログラミングの世界（ドメインモデル）と実装技術の世界で、関心事が明確に分かれているため、ソースコードが理解しやすくなり、全体の見通しが良くなります。

その結果、改修も楽になり、ソースコードの変更コスト、テストコスト、デグレのリスク低減など、さまざまな効果がうまれ、さらにその効果は長期にわたり続きます。

手続き型プログラミング

一方、手続き型プログラミング*2はどうでしょうか。

以下の図は手続き型プログラミングの全体像を表しています（図3-4をもとに私が作成）。

手続き型プログラミングでも、オブジェクト指向プログラミングと同様、現実世界の業務が関心事です。

しかし同時に、実装技術の操作も関心事なので、うまく共通化などを図っていたとしても、時間とともに、現実世界と実装技術という２つの関心事がソースコード内に混在してしまうことは避けられないでしょう（特に複数人での開発時）。

その結果、ソースコードも可読性がさがり、見通しが悪くなってしまいがちです。

以下の図を、オブジェクト指向プログラミングの図と比べると、手続き型プログラミングでは、開発が進むにつれ、ソースコードが次第に複雑になっていくイメージがつくのではないでしょうか。

【オブジェクト指向プログラミングの図を再掲】

テストコードの書きやすさ

ドメインモデルと３層で関心事が分かれていて、ドメインモデルは実装技術（Webやデータベースなど）から切り離されているので、システムで最も重要な、業務ロジックのテストコードが書きやすくなります。

「テストコードが書きやすいプログラム設計」を模索している人は、本書で説明されているオブジェクト指向プログラミングを学ぶとよいでしょう。

本書の構成

では、オブジェクト指向プログラミングで、３層＋ドメインモデルをどのように設計し、プログラミングしていけば良いのでしょうか。

本書では「ドメインオブジェクト」「ドメインモデル」「データソース層とドメインオブジェクト」「アプリケーション層の組み立て方」「プレゼンテーション層とドメインオブジェクト」など、実装パートごとに分割し、それぞれの考え方やテクニックを具体的な事例を示しながら説明しています。

必要に応じて、実装パートごとに読んでいくのもよいでしょう。

本書の構成について、以下にまとめたので、読み進める際の参考になればと思います。

• ドメインオブジェクト

  • 1章：小さくまとめてわかりやすくする
  • 2章：場合分けのロジックを整理する
  • 3章：業務ロジックを分かりやすく整理する

• ドメインモデルの設計

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

• アプリケーション層

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

• データソース層

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

• プレゼンテーション層

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

• その他

  • 8章：アプリケーション間の連携
  • 9章：オブジェクト指向の開発プロセス
  • 10章：オブジェクト指向設計の学び方と教え方

本書の特徴

本書を読んで感じた特徴をあげていきたいと思います。

すぐに始められることから説明されている

オブジェクト指向プログラミングというと、システムの全体設計から始めないといけないのかと、身構えてしまう人もいるかもしれません。

本書では、クラスやメソッド、変数の名前の付け方、メソッドの抽出の仕方など、すぐに始められるところから説明が始まっています。

オブジェクト指向プログラミングを経験しながらすぐに学び始めることができ、段階的に身につけることができるでしょう。

実践的で具体的なエッセンスが網羅されている

オブジェクト指向を説明している書籍は、抽象的な説明が多い傾向があります。

本書では、具体的にソースコードを提示し、なぜそうするのか、どのような効果があるのかも合わせて説明されていますので、実践でのイメージが湧きやすくなっています。

また、ドメインモデル、ドメインオブジェクトの設計だけではなく、プレゼンテーション層（画面）とドメインオブジェクト、データベース設計とドメインオブジェクト、APIの設計など、現場ですぐに使えるテクニックが網羅されています。

豊富な実践経験、日頃の研究・試行、思索が凝縮されている

著者の増田さんは、大規模システム開発などで長年にわたりオブジェクト指向プログラミングを実践し、そこでの経験に基づき本書を執筆されています。

本書には「エリック・エヴァンスのドメイン駆動設計」「実装パターン」「リファクタリング」など16冊の参考書籍が掲載されています。

増田さんはこれらの書籍と自分の理論を突き合わせ、実践で試行し、さらに実践から自分の理論を構築する、という過程を経て生み出されたのが本書ではないでしょうか。

また、増田さんのTwitterのアカウント@masuda220からは、日頃からDDD、オブジェクト指向プログラミングについての思索が流れてきます。

そのように日々、オブジェクト指向プログラミングのことを深く考えている増田さんの説明には納得感を感じられます。

オブジェクト指向プログラミングを学ぶ時のインデックスとして活用できる

各章の終わりには、参考書籍の該当章が示されています（たとえば3章の末尾には『エンタープライズアプリケーションアーキテクチャーパターン』「第1章 レイヤ化」「第9章 ドメインロジックパターン」『ドメイン駆動設計』「第4章 ドメインを隔離する」、『改訂新版Spring入門』「第1章 SpringとWebアプリケーションの概要」が提示されています）。

深く学びたい方は、参考書籍の該当章を読むことで、さらに理解を深めることができます。参考書籍は、それぞれボリュームがありますので該当章が提示されているのはとても助かりますし、オブジェクト指向プログラミングを学ぶときのインデックスとして使えるでしょう。

オブジェクト指向プログラミングを始めることで得られるもの

オブジェクト指向プログラミングを身につけると、さまざまなものが得られます。

時間

冒頭であげたシステム開発における問題点、たとえばソースコードの可動性が低い、全体を把握するのに時間がかかる、影響範囲の調査に時間がかかる、などによってシステム開発の作業時間は少しずつ伸びていきます。

これらが当たり前になっているのは、手続き型プログラミングのシステム開発時代の時間感覚です。

オブジェクト指向プログラミングを実践すると、影響範囲の調査、プログラミング、知識の伝達、テスト、不具合調査など、さまざまな時間が短縮されていきます。システム開発チームは正のスパイラルで成果を出し続けることでしょう。

「現場で役立つシステム設計の原則」を読み、オブジェクト指向プログラミングを学び、実践すれば、システム開発にかかるさまざまな時間を短縮できます。

オブジェクト指向プログラミングにより、システム開発現場の働き方改革にもつながるのではないでしょうか。

ものごとの本質をつかみ、表現する力

オブジェクト指向は、複雑な現実世界の関心事を、UMLなどのモデルやソースコードとして抽象化します。それを繰り返すことにより、以下のような力がついてきます。

• 目の前の事象の重要なことは何か、本質は何かを把握する力
• 自分が理解したことをわかりやすく表現する力

このようなスキルが身につくことによって、急所を押さえた仕事ができるようになり、他の人にも的確に情報が伝達できるので、結果的に仕事が格段に速くなるでしょう。

ソフトウェア開発者としての自信

オブジェクト指向プログラミングを実践すると、日頃の設計の積み重ねにより、機能追加、機能改修のスピードが速くなります。

短い時間で機能追加、改修ができる自分や、それを可能にするシステム設計ができている自分に自信をもてるようになります。

機能追加、機能改修が速く完了すると周りからも喜ばれ、評価も高まりますので、さらなる自信にもつながるでしょう。

まとめ

実装技術は数年で変わっていくものですが、本書で説明しようとしているオブジェクト指向プログラミングは普遍的なものといえるでしょう。

真の実力を身につけ、長期的に価値を生み出し続けたいプログラマーにおすすめの一冊です。

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

*1:オブジェクトの振る舞いを隠蔽したり、オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの実際の型を隠蔽したりすること

*2:手続き型プログラミング（てつづきがたプログラミング、英: Procedural programming）は、「手続き呼び出し」の概念に基づくプログラミングパラダイムの一種。命令型プログラミングと同義に扱われることが多い。「手続き」はプロシージャ、ルーチン、サブルーチン、メソッド、関数（数学の関数とは異なる。）など様々な呼称があるが、実行すべき一連の計算ステップを持つものと定義できる。WikiPedia：手続き型プログラミング