SE(たぶん)の雑感記

一応SEやっている筆者の思ったことを書き連ねます。会計学もやってたので、両方を生かした記事を書きたいと考えています。 でもテーマが定まってない感がすごい。

『現場で役立つシステム設計の原則』を読んだ

電子書籍ですが、読みました。

honto.jp

買って一週間程度で読み終わってはいたのですが、間が空いてしまいました。

きっかけ

私はDDD(ドメイン駆動設計)を知ってから、ソースコードの重要性や、設計の楽しさに興味を持ちました。
それが高じて、システムアーキテクトを取得してしまう程度には、設計について様々な知識を集めていました。

細かい開発で使うことはあっても、使う機会に恵まれないのが痛いところですが。

独学でDDDを勉強しているときに、日本でDDDを推進・実践している、著者のことを知りました。 その人が書いた本なら買うしかない!ということで、買いました。

…書店で買いたかったのですが、どうしても行く時間が取れず、泣く泣く電子書籍です。

なお、以下の二書籍は読了しています。(以下、『DDD本』と呼称)

honto.jp

honto.jp

すごくどうでもいいですが、DDD本は紙媒体も電子書籍も持っています。紙を先に買ったからなんですけどね。
現在(2017/07/28)、サイト見たら「読割50」と「30%OFF」で1,600円とかなんですが…安い。

こういう人にお勧めしたい

あえて感想の前に持ってきました。

私が思うに、この本は、こういう人にお勧めです。

  • ソースを綺麗に書けるようになりたい
  • ソースは書けるようになったけど、それだけだなぁ、と考えている
  • DDD本が分厚すぎて辛い…けど勉強したい
  • オブジェクト指向がいいらしいけど、なんだかよく分からない

感想

一言で言うと…


わかりやすい!


です。

リファクタリング、DB設計、画面設計、WebAPI設計、開発プロセス、DDD…

これだけの内容が、分かりやすく、コンパクトにまとまっているのは、ただただ驚嘆です。

考えとしては一つで、「変更を楽で安全にする」ことであり、全てその視点で書いてあります。
その手段がオブジェクト指向であり、ドメイン駆動設計です。

ソースコードレベルで、どうやって綺麗にするか、という点と、設計レベルでどうやって綺麗にするか、の両方の点を、一つの考え方で貫いており、実に理解しやすいです。

この本を使って、プログラミングをある程度経験した若手に研修したら、効果が見込めると思います。*1

DDDについて

ドメイン駆動設計は、複雑な設計なシステム*2を、いかにわかりやすく構築するか、という点に主眼が置かれています。
実現のための様々なエッセンスがありますが、結局言いたいことは、

  • 対象領域について、ドメインエキスパートと開発者間で、モデルレベルで合意を取る*3
  • そのモデルの用語を使ってシステムやプログラムを構築する

ことです。

特に後者は力を入れて*4解説されており、この実現手段を解説したのが、DDD本です。
しかし、それ故に本は分厚く、研修しようにも、教える側も教わる側も挫折する始末…
人に勧めても、分厚さ故に敬遠される…という側面もあります。

難解なのは、『実践ドメイン駆動設計』が出るまでに10年かかったことからも、伺い知れます。

ただ、以降の様々な書籍に、ドメインモデルの考え方は入っています。

これとか、

honto.jp

これとか

honto.jp

です。

個人的には、開発者にとっては、プログラミング言語以外の、もう一つの言語と言っても過言ではないほど、重要だと考えています。

本書は、DDDの入門書としても、非常に良いと思います。
これまで、小さなソースのレベルでDDDと絡んだ書籍は無かったので、そういう意味で本書はDDDの入門書と言えると思います。

まとめ

汚いソースに苦しみ、やりたいことができないという経験をした人はいっぱいいると思います。
じゃあどうすればよいのか、ということを学びたい人もまた、多いと思います。

そのときには、本書を読み、もっと深く学びたいときは、本書の参考書籍を読めばよいと思います。

例えば、本書の参考書籍で『リファクタリング』が挙げられています。

honto.jp

リファクタリング』に書かれている内容は、一部本書にも書いてあります。
が、やはり、元の本のほうが情報が多い*5ので、不明点はどんどん本を読めばよいと思います。

あと、本当に強く思ったのは、どんどん実践例が増えていき、必要な情報のみがまとまった本が出てきたなぁ、というものです。
DDDもリファクタリングも、それを実践して初めて価値があるのですが、実践して本当に価値があったものが、本書を含めた後続の書籍には、書かれています。

実践例から、原則に向かう、というのも、一つの学びの方法だなぁ、と思いました。

開発者なら、ぜひ、読みましょう。(宣伝)


*1:社内でいずれやりたい。

*2:基本的には、業務システムを前提にしている気がする

*3:言い換えると、関係者が同じ土俵に立つための、言語を構築する。同じ土俵で話す

*4:前者も非常に重要だと説かれているが、業務による個別的要素が多く、そもそも体系立てての解説が難しい

*5:故に分厚い