いやー、私が紹介するまでもなく、有名な名著だと思いますが。

ほんっといい本。

しかし、超読みにくい。

翻訳のせいもあるのかもしれない。

分厚いのもありますが、7月から読み始めて、なんと8か月もかかりました。(´ω`)

 

ぜひ、プログラミング始めて3年目ぐらいの人たちに読んでほしい。

プログラミングというのは難しいな、と感じ始めた人たちに読んでほしいです。

特に、内容は自分がかかわらない分野の業務システムなどを作るプログラマーにとって必要な知識があります。
とはいえ、C向けのプログラムでも大切な内容も含まれています。

内容は豊富すぎるのですが、あえて私が注目したことをまとめておくと

①その業務分野のプロの話をよく聞くこと。

②言葉の定義をちゃんとする（ユビキタス言語）
〇〇さんの開発しているあの機能とか言わずに、ちゃんと名前にする
そして、共同作業するプログラマー全員がその言葉をちゃんと理解する

③モデルをちゃんと作る
モデルというのは概念。概念がちゃんとしていないと、よいプログラムにならない
ここで、①が重要になってくる。その業務分野のプロの話していることをちゃんと理解して、何が重要なのかをつかむことが大事。

④ソフトウェアを常に進化させ続けるために、しなやかな設計にする
作らないことにはわからないことが多すぎる。（本当に）
常に前進するのを恐れない。

 

特に、私が衝撃を受けたのは③ですね。

モデルとは概念なのだ！！

プログラミングとは、概念を読んでわかるようにすることなのだ！！

 

もうね、ヘレンケラーが

「Water！！！！」

と叫んだような衝撃ですよ。

そういわれればそうなんだけど、地球が大きすぎて見えないように、それに気づいてなかった。

私の今までやってきたプログラミングは小手先だったなと感じました。( ﾟДﾟ)

やりたいことをやるためにプログラムが存在し、将来の自分やチームメイトがわかりやすいようなコードを志してやってきてましたが、そうか、概念か。

 

逆に言うと、プログラミングをしていて、はっきりしてくる概念もあるわけです。

この体験を最近しまして、今弊社で「ODIN リアルタイム配送システム」にある機能をつけているのですが、そこで、なんか仕様がモヤモヤしているところがあるわけですよ。

コードを見ると、配列でいろいろif文を駆使してなんとかやっている。読むのが大変なやつです。

で、ドメイン駆動設計の考え方に基づいてクラス設計をやり直したら、驚くほどコードがすっきりしまして。

そしたら概念がクリアになったので、仕様がすっきりしました。

そしたら、弊社のソフトウェアが持つ特徴、他のソフトにはなく、うちがお客様に届けるべき価値も明らかになりました。

 

というわけで、杏寿郎、お前もドメイン駆動設計（DDD）をしてみないか。

おススメの本です。