「祝完読！ しょぼちむのエヴァンス本のススメ」(勉強会)に参加してみた感想や気づきなど

はじめに

「祝完読！ しょぼちむのエヴァンス本のススメ」という勉強会に参加したので、

勉強会での内容を気になったポイントに絞ってまとめ、僕の感想や気付きなども書いてみました。

＞＞祝完読！ しょぼちむのエヴァンス本のススメ

2022/3/22追記

今まで僕が参加した回の

現場から学ぶモデル駆動設計の勉強会での学びや気付きなどについて

まとめ記事を作ってみました。

現場から学ぶモデル駆動設計勉強会のまとめ記事

「祝完読！ しょぼちむのエヴァンス本のススメ」(勉強会)で印象に残ったところや気づきなど

勉強したことをアウトプットしたり、いい情報発信をしているところにいい情報が入ってくる

しょぼちむさんが100日かけて勉強したことを毎日アウトプットしたことで、

Twitterなど通じてコメントなどドメイン駆動設計に関するいろんな考え方や情報が集まった。

とのことでした。

以前別の人から同じようなことを聞いたことがありましたが、

勉強したことのアウトプットは、自分の理解を深めるだけでなく、

そこにいい情報が集まるという意味でも大事なことなのだなと改めて思いました。

ビジネスサイドとコミュニケーションをとるような立場になるほどこの本の良さが分かる

業務をある程度経験していろんなステークホルダーとやりとりするような立場になると

この本の良さがよく分かる。逆に新卒にエヴァンス本を読めと言う人はこの本を読んでない人じゃないか。

という話がありました。

自分も、(エヴァンス本ではないですが)ドメイン駆動設計の勉強をしていく中で、

ドメインエキスパートを巻き込んでモデリングを進め、

モデリング結果をそのままドメインオブジェクトにマップさせて開発をする。

モデリング結果をいろんなステークホルダーとの共通言語として使う。

というような考え方を現場でも取り入れていこうと活動しています。

ビジネスサイド含めたステークホルダーとのコミュニケーションという観点でもやはり

ドメイン駆動設計の考え方というかエヴァンス本で書かれていることは重要なことが書かれているのか！！！

(でも読むのはしんどいな、、、）って思いました。

アーキテクトはドメイン知識を全く知らずにシステムの基盤部分が作れる時代もあったが、今は違う

ドメイン知識がシンプルでDBから取得したデータ加工さえ効率よく性能良くやれる基盤の仕組みができれば、

あとは誰が作ってもいいという時代があり、

その場合は開発チームの優秀なメンバーを引き抜いてアーキテクトチームを中央集権的に作る。

というようにすれば確かに効率が良かった。

しかし、

今は、ドメイン知識が複雑なシステムを作るケースが多く、それでは通用しない。

というような話がありました。

自分も基盤チームがいて個別システム開発担当がいるような現場の

個別システム開発担当側で仕事をしたことがありましたが、

基盤チームへ(社会人２年目くらいでしたが)僕が文句言いまくってたのと、上司から言わされてたので、

基盤チームへのフィードバックはある程度できていて、

個別システムの意見も取り入れてもらっていたかなぁと思います。

複雑なドメイン知識を抑えた上で全体設計をし、

ドメイン知識を抑えた上でそれに沿った形で基盤部分を作るなら意味があるでしょうが、

そうでない場合は、ドメイン知識を抑えていないアーキテクトは不要なケースが多いのかなと思います。

この辺りが勉強会で個人的に気になったポイントでした。

他にも雑談の中での設計周りの話で、

という話が出ました。どちらも自分の中では意識しているポイントだったので、

そうだよなぁと思いながら聞いていました。

ちょうど、増田さんの「現場で役立つシステム設計の原則」を改めて

自分の理解を確かめながらサンプルコードを作りながら読み進めているのですが

変更を楽で安全にという考え方は本でも出ていたなぁと。

命名と小さく分けることの関係と重要性〜ソフトウェア設計のきほん〜

分岐を丁寧に扱う理由とその方法〜ソフトウェア設計のきほん〜

終始しょぼちむさんニコニコ笑顔で、旦那さんもエンジニアで

なんかいろいろ楽しそうで羨ましかったなぁ・・・・

(家でも設計談義とかめっちゃしてんのかな)