でぐれない

全てのデスマーチを生まれる前に消し去りたい

「現場で役立つシステム設計の原則」でDDDをかじってみたよ

最近私はDDDに興味があって、入門向けっぽい記事をチェックしていたんだけどその中に書籍を紹介してくれているのを見かけてさっそく読んでみたよ。

omuriceman.hatenablog.com

なんなら「実装ドメイン駆動設計」も買ったよ。

とてもとても参考にさせていただきました。

 

設計の本を読んだことは前にもあって、これも勉強になったね~

 

err.hatenablog.com

 これ読んだときは設計とは何をする行為なのかも漠然としていたから、

設計って何をすることで、どこがゴールなの?って考えていたしそれを教えてもらった気がする。

それより今はもうちょっと自分的には進んでどう設計するのが良いかみたいな方向性で読めた気がする。

 

内容は目次見たらわかるから、すっとばします。

自分の気づき

・業務要件とシステム要件が区別できていない

・「小さくまとめる」が想像よりずっと小さい

・Web APIがわからない

読んだ感想

・今のプロジェクトがDDDで設計されてるわけじゃないけど、触れるところでその考え方を落とし込むことはできそうだし、

例えばDDDにするとしたらって考えることはできる気がするからちょっと考えてみたいところ(というか、そうしないとふーんそういう設計があるのねで忘れちゃいそう)

・やっぱり今も作ってるものとしては業務知識ありきってかんじだし、それをうまく表現されていないから起こっている設計不備みたいなの感じるし、どうしたらいいのか悩ましいね~

いちばん、おお!ってなったところ

 「分析と設計が一体になった開発のやり方をマネジメントする」っていうところの

 分析・基本設計と見積までが準委任、その後続の工程は請負が一般的だけど

 準委任にしたほうが、その後の仕様変更などにも対応しやすいって書いてあるところ。

 たぶんそうしてもらわないと、開発する側はきついし、品質落として納期を守る的なプロダクトよりもプロジェクトを優先する状況になっちゃうんだよな。

 エンドユーザーのこと考えると、どうなのかまだよくわからないや。

にばんめにおお!ってなったところ

 同じところの「要員と体制」ってところで

 プログラミングできても業務知識を意欲的に学ぶことが大事だよって書いてあった!

 どきっとするよね~次から商談する時にそういうこと聞いてみようかな

 

DDDが何なのかってところはまだわかってないけど、

ドメインのことがちょっとわかった!

あと理想が少し見えた!

変更が楽で、実装が説明書になりうる(ソースコードが第一級のドキュメントと書いてある)状態。

とても勉強になりました。

次は「実装ドメイン駆動設計」を読みます。

こっちは倍くらいボリュームありそうだしでかいし、読むのに時間かかりそう。

エヴァンス本にも興味はあるんだけど、とりあえずこっちを読んだ上で考えるかな。