「ドメイン駆動設計入門」という本を読みました

この本は、会社のM君が読んでいて、この本の話をよくされるので、「私も読んでおくか~」となって読みました。

この本を読んで、ドメイン駆動設計の復習になりましたし、新しい知識もあって大変勉強になりました!⊂(^-^)⊃

忘れてたことも多いしね(笑)

 

この本は、ドメイン駆動についてコードをベースにわかりやすく紹介してくれているのが特徴かなと思います。

前にドメイン駆動と言えばこれ みたいなエリック・エヴァンスという方の本があって、そのレビューを書きましたが

「エリック・エヴァンスのドメイン駆動設計」を読みました

上記の本は、いい本なんだけど、とにかく読みにくいし、長い!

エリック・エヴァンスの本は、考え方、みたいなのについて述べられている部分が多いので

「とにかくコードで見たい」

という方には退屈になるだろうなと思うんですよね。

実際、私も読んでいる間、何度も昼寝しました(笑)。

 

なので、手っ取り早くドメイン駆動を学びたい、コードで紹介してほしいという方にはこっちの「ドメイン駆動設計入門」がおすすめかもしれません。

ただ、「ドメイン駆動設計入門」にも書いてあることですが、私としてはエリック・エヴァンスの「エリック・エヴァンスのドメイン駆動設計」とセットで読んでほしいなと思います。


下記、メモです。

<値オブジェクトとエンティティ>

値オブジェクトは、電話番号とか、名前とか、ユーザーidとか。
ユーザーidが例えば6文字以上、とか名前が性と名からなるとか、そういうのをオブジェクトにしておくと制約をコードにしておけるので作りやすい。不変にしておくのがよい。
エンティティは、ユーザー、とか。ユーザーの年齢が変わっても同じユーザー。
識別子で識別されて同一性が担保される。

<凝集度>
クラスのプロパティが、どのメソッドで使われているか。
すべてのプロパティが全部のメソッドで使われていたらめちゃ高凝集。

<集約>
UserクラスとCircleクラスがあって、たとえばユーザーをサークルに追加する処理、というのを
ユーザーアプリケーションに
circle.members.add(member) としてはいけない。
例えば、サークルに人数制限がある場合、circle.members.add(member)  とするたびに、サークルのメンバーが30人以下かどうか、という確認をcircle.members.add(member)する前に確認するとする。
すると、circle.members.add(member) を呼び出すたびにそれをしないといけないと、プログラム上DRYの原則に反しているし、Circleというクラスにその人数制限の表現ができていないから。
CircleクラスにJoinというメソッドを作ってそこで定義するべき。

<仕様>
仕様をプログラムにするのもいいかも。
前述のCircleで例えると、メンバーを種別で分けることになり、例えばプレミアムユーザーは5人まで、とかルールが複雑になっていくことが考えられる。
その場合
CircleMembersFullSpecipication
というクラスを作って、そこでサークルメンバーに対する複雑な仕様を書いておく。
そうすると、サークルメンバー追加という場合に、CircleMembersFullSpecipicationを呼び出して、仕様にあっていれば追加、とすればよいので楽だしコードが読みやすい。


プログラムの書き方って本当にどうやって書いたって自由なんですよ。

私の好きな言葉に “Code is Poetry” (コードは詩である)というものがあります。

詩はどう書いたって自由です。

が、読むほうにすれば、やはり優劣があります。

いい詩はスッと入ってきますね。

言葉と概念の選び方なんだと思います。

詩人ってセンスが大切みたいな思うかもしれませんが、めちゃくちゃ作品を書いてるんですよね。

松尾芭蕉も確認されただけで1000句も詠んでいたらしいです。

コードもやはり、書いてきた量とプログラマーのスキルというのはある程度比例するなと思うときがあります。

「古池や蛙飛び込む水の音」

ぐらいなプログラムが書けれたら最高ですね⊂(^-^)⊃