勉強会での内容を気になったポイントに絞ってまとめ、僕の感想や気付きなども書いてみました。今まで僕が参加した回の現場から学ぶモデル駆動設計の勉強会での学びや気付きなどについてまとめ記事を作ってみました。ちむのエヴァンス本のススメ」(勉強会)で印象に残ったところや気づきなど勉強したことをアウトプットしたり、いい情報発信をしているところにいい情報が入ってくるしょぼちむさんが100日かけて勉強したことを毎日アウトプットしたことで、Twitterなど通じてコメントなどドメイン駆動設計に関するいろんな考え方や情報が集まった。勉強したことのアウトプットは、自分の理解を深めるだけでなく、そこにいい情報が集まるという意味でも大事なことなのだなと改めて思いました。ビジネスサイドとコミュニケーションをとるような立場になるほどこの本の良さが分かる業務をある程度経験していろんなステークホルダーとやりとりするような立場になるとこの本の良さがよく分かる。逆に新卒にエヴァンス本を読めと言う人はこの本を読んでない人じゃないか。自分も、(エヴァンス本ではないですが)ドメイン駆動設計の勉強をしていく中で、ドメインエキスパートを巻き込んでモデリングを進め、モデリング結果をそのままドメインオブジェクトにマップさせて開発をする。モデリング結果をいろんなステークホルダーとの共通言語として使う。いうような考え方を現場でも取り入れていこうと活動しています。ビジネスサイド含めたステークホルダーとのコミュニケーションという観点でもやはりドメイン駆動設計の考え方というかエヴァンス本で書かれていることは重要なことが書かれているのか!!!(でも読むのはしんどいな、、、)って思いました。アーキテクトはドメイン知識を全く知らずにシステムの基盤部分が作れる時代もあったが、今は違うドメイン知識がシンプルでDBから取得したデータ加工さえ効率よく性能良くやれる基盤の仕組みができれば、あとは誰が作ってもいいという時代があり、その場合は開発チームの優秀なメンバーを引き抜いてアーキテクトチームを中央集権的に作る。いうようにすれば確かに効率が良かった。今は、ドメイン知識が複雑なシステムを作るケースが多く、それでは通用しない。いうような話がありました。個別システムの意見も取り入れてもらっていたかなぁと思います。複雑なドメイン知識を抑えた上で全体設計をし、ドメイン知識を抑えた上でそれに沿った形で基盤部分を作るなら意味があるでしょうが、そうでない場合は、ドメイン知識を抑えていないアーキテクトは不要なケースが多いのかなと思います。この辺りが勉強会で個人的に気になったポイントでした。設計の価値は変更で楽で安全にできること振る舞いが違う、不変条件が違うなら別物という話が出ました。どちらも自分の中では意識しているポイントだったので、そうだよなぁと思いながら聞いていました。増田さんの「現場で役立つシステム設計の原則」を改めて自分の理解を確かめながらサンプルコードを作りながら読み進めているのですが変更を楽で安全にという考え方は本でも出ていたなぁと。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。