社内でドメイン駆動設計入門の読書会 #15

2020/06/08 2020/06/08

こんにちは。Nonです。

今回も会社で読書会をしている話をしようと思います。

内容は控えめに、ディスカッションの内容重視で書いていきたいと思います。

より具体的なコードや内容がみたい！という方は購入しましょう！

前回：会社でドメイン駆動設計入門の読書会 #14

読んでいる本

読んでいる本はこちらのドメイン駆動設計です。

以前の記事でも言っていたように、業務でDDDを利用して開発することが多くなったのですが、DDDに精通している人が少ないという問題がありました。

そこで、その精通している人が読書会をしようかと誘ってくださいまして、是非にと参加させていただきました。

読書会の進行方法は

という進行方向となっています。

社内で読書会をするのはこれが初めてなので、進行方法はもっといいのあったら教えて下さい。

でも、ドメイン駆動はドメインに注目して開発していく設計なので、コードは実はあまり関係ないのかもしれません。もちろん、コードが二の次というわけではなく、コードはドメインを反映させるためのふさわしい構造になっていないといけません。

この記事を読んでいる皆さんにはすでに周知のとおりですが、変数名は重要です。
変数名はその処理を追うための手かがりになるからです。

ドメイン駆動設計でもこの点に触れていて、create, make, registerや、update, saveなど、普段何気なく使っている変数名や関数名について触れています。

ドメインで頻出する単語はそのドメインにとって重要なので、それもコードに反映しなければなりません。

例えば、あるドメインで、ユーザー登録ではなくエージェント登録という内容であれば、userではなくagentという名前になりますし、ユーザー更新ではなくユーザー保存と慣ればsaveUserとなります。

この微妙な命名でコードとドメインが乖離してしまう原因になってしまうのです。

これはまだ完全に理解できていないので、今後の課題とします。

実は結構前に、ドメイン駆動設計の全ての章を読み終えて、業務のコードに実装まで始めていました。実際にコードにするとなると非常に難しく、軽量DDDになってしまっている感が否めません。今後も精進していきたいです。

常時、自社プロダクトにコミットしているので、自分の作成したプロダクトくらい自分の支配下においていきたいものです。ということはドメインに一番詳しいのは、自分たちということになります。

そういう意味でも、ドメイン駆動設計を用いて、自分たちが実現したいことをコードで表すことは義務であるのかなと思います。

読書会は引き続き進めているので、機会があればまた連載記事として、掲載していこうと思います。
その時はよしなに。