DDD社内勉強会運営記事(1) DDDに見る夢
はじめに＆おことわり
2021年度下半期、社内でDDD勉強会を主催しました。主催しよう！と思って始めたわけではなく、軽い気持ちで「ドメイン駆動設計」を読み、部署内でオススメしたところ、「やってみれば？」とそそのかされた形です。若手のメンバーとDDDに対する理解が深められたのも良い点でしたが、モブプロしたり、社外からスペシャル講師を招いた会をしたり、個人的には楽しくやりがいのある会でした。
その勉強会について書く前に、本記事では、DDDに対して個人的に抱いている夢を書こうと思います。DDDは、システム開発にかかわる全員がハッピーになるもの（のはず）ではありますが、特に、私と同じようにプログラミングが好きな人には「刺さる」だろうな、と思っています。実装が退屈な人、昔は楽しかったのにな。。。と思っている人に、DDDにトライすることで、楽しい気持ちを新たに呼び起こしていただきたいな、という動機で書きます。
記事を読むにあたっての注意、おことわりを最初に挙げます。ご了承いただいたうえでお読みください。
「DDDとは何か」の説明はしません
ネット上にも良い記事はたくさんありますし、私としては本を読んで勉強することをお勧めします。本記事最後に参考図書含め私の勉強方法を紹介しますので、ご参考ください。
実装者視点で書きます。対象読者は実装する人です。
私自身が、実装が好きで、DDDについて抱く夢も実装者視点のものであるため、です。
私見、「個人的に」抱いている夢です。
有識者の中には、DDDで「そうはならんやろ」と思われる方もいらっしゃるかと思います。あくまで、私の理解を元に、「こういうハッピーな世界もあるのでは？」という夢を語ります。
DDDでない世界って？
いくつかプロジェクトを経験してきましたが、私がいた世界はおおむね、DDDでない世界でした。プロジェクトにより細かい点は当然違いますが、話をしやすいよう、たとえばこんなDDDでない世界を誇張して考えてみます。
仕様はプロマネがお客さんと調整して決めてくる。お客さんのことを仕様ホルダーと呼んだりする。どうしても実現が難しい場合は調整して変更することがあるものの、基本的には「決まったものが落ちてくる」もの、それが仕様。
アプリケーション構成、アプリケーション内のアーキテクチャ、利用するライブラリ・フレームワーク、採用するDBやその設計は、比較的「技術できる」エンジニアが担当する。その人をアーキテクト・インフラ担当・DBAと呼んだりする。実装するうえで困ったことがあればその人たちにいろいろ相談するが、おおむね「決まったものが落ちてくる」。
実装者が詳細設計・実装・自動テストを書く。書くべき処理はおおよそ決まっていて、たいていは、あらかじめ作られたDBスキーマにデータをCRUDするものであり、最短工数で愚直に手続きを書けばよい。仕様についてわからないことがあると、アーキテクトやプロマネに聞くと仕様ホルダーに確認してきてくれる。実装についてわからないことがあると、アーキテクト・インフラ担当・DBAに質問すると、答えてくれる。
お客さん、プロマネ、技術できる人は忙しく、よほどの問題が無い限り意見しづらい雰囲気がチーム内にある。
この例で実装者の私に、役割分担や自分の仕事に対する不満はありません。面倒なことは他の人が調整してくれるし、実装に集中はできるし。複雑な手続きを頑張って作って動いたら、「やってやったぜ！」と充足感を得られることもあるでしょう。
しかし、ちょっと違うな、もっといい感じにならないかな、と思うこともあります。
実装を終えつつある状況で、もっと"いい感じ"の実装をおもいつきます。仕様もしくはアーキに影響がありますが、きっとシステムはよりよくなり、利用者にも喜んでもらえるはず。事前に実装のイメージを固められてたら、と後悔に似た感情を持ちますが、今言い出しても「この仕様でお客さんはOK出してるから」「動いてるものをいまさら変えるなんて、そんな工数ないよ」と言われることが目に見えてる。残念だけど、このアイデアは誰にも言わないでそっと心に留めておこう。。。
複雑な処理を頑張って作り上げた。自動テストもちょっと通るので問題はないものの、出来上がったのは、縦にも横にもながーーーーい実装。もっとメソッド分割などリファクタリングしてかっこいい実装にできる余地はありそうなんだけどな、と思うものの、仕事はまだまだたくさんあるし、いつまでもこの実装をこねこねする時間はない。この実装に不具合があったら、関係する部分に追加開発があったら、担当する人は大変だろうな、と申し訳ない気持ちを感じつつも、「俺の力とこの状況ではこうせざるを得なかったんだよ。。。」なんて、誰にでもなく言い訳を考えながら、コードレポジトリにpush、プルリクを作成する。。。
（リアルなプロジェクトの実装のため、モザイクをかけています）
大袈裟に書いてますが、実装する人には、どちらも「まぁあるよね」と思っていただけるのではないでしょうか。
DDDに見る夢
DDDな世界は、実装で得た「ドメイン知識」を、仕様ホルダーも含むチーム全体で共有し、よりよい仕様・設計にしていく世界、とのことです。
実装やリファクタリングの工程で、処理についてひらめきを得ることがあります。このひらめきはドメイン知識となりうるものであり、実装に反映し、チーム全体に共有することで、システムを改善していく、それがDDDの考え方の一面です。
そして、まさにこの点に、実装者である私は夢を見ています。夢、と呼んでいますが、これらが荒唐無稽であると思ってのことではなく、きっと「いい世界」が待ってるぞ、という期待を込めてのワードチョイスです。DDDな世界はきっとこんな、夢見るような世界で、私はそんな世界で仕事をしたいと思っています。
実装者の知見をお客さんも含むチーム全員で共有できること。
実装者の価値が最大限に生かせること。実装者冥利に尽きるとはこのことだと思います。
同じ言葉を使うこと、同じ価値を共有すること、一つのゴールを目指すこと。ワンチームとして動けること。
チームビルディングの話のようになりますが、チーム内の不要な垣根を壊してお互いの仕事を理解し合うことで解消する不満があります。そのためには、不要な翻訳を挟まないで同じ言葉でチーム内の誰もが話をしあえることが近道になると信じています。
愚直に処理を実装すると活かす機会があまり現れない、オブジェクト指向由来のプログラミングテクニックを、ドメインの構造として活躍させられる。
この点が一番私を興奮させた点です。Evans本にも、ドメイン駆動設計にもデザインパターンへの言及があります。C++を使ったときのスタンダードライブラリのvectorに対する感動。JavaのCollectionライブラリのクラス設計に対する感動。デザインパターンの出会い。自分もこういう設計を活かせるようになりたい、と強く思ったXX年前の強い欲求。。。なぜ忘れていられたんだろうと思います。
私の勉強の仕方
DDDに対して興味を持っていただけましたでしょうか。興味は持てたけど、DDDとは何か、どうやって勉強しようか。。。そう思った方に、ここで私がDDDを学んだ方法を例としていくつか紹介します。是非ご自分にあった方法を探してトライしてください。
書籍を読む：一番の勉強方法はやはり書籍にあたることかな、と思います。Web記事等でDDDについて読んで、完全に理解したつもりの私は、「実践ドメイン駆動設計」を読んで目からウロコが落ちました。以下は私の本棚に並んでいるものです。もちろんおススメではありますが、相性のようなモノもあると思いますので、是非いくつか手にとってみてください。もちろんここでリストアップしていない良い本もたくさんあります。読むスタイルも人それぞれだとは思いますが、個人的には、頭からしっかり読むというよりは、わからないところはわからないまま読み進めたり、読み進めてはまた戻ってみたり、何巡も読み直すような読み方がお勧めです。
SNS：上記書籍著者など、様々なSNSでDDDについて情報発信している方がたくさんいらっしゃいます。是非フォローして、著名な方々が日常的に発信するメッセージからDDDのエッセンスを吸収していただければと思います。
webiner：かなり頻繁にDDDについてのwebinerが開催されています。conpassやSNSで探してみてください。
自分でやってみる：本を読み、人の話を聞き、「完全に理解した」と思っていても、いざ実際に手を動かしてみると、なかなか手が進まないものです。自分が何を理解できていないかを知るためにも、実装してみましょう。一人でもよいですし、仲間を募っても良いです。現在関わっているシステムについてでも、まだ世にない新しいシステムでも良いです。いきなり大きなプログラムを作ろうとすると大変なので、小さなものからトライしてみるのがよいのではないでしょうか。
次回予告
さて、「DDDに見る夢」ということで、私がDDDの何に惹かれて熱くなっているのか、同じように実装が大好きな人にその思いを共有したい一心で書いてみました。気持ちだけでも伝わっていれば幸いです。
次回は、社内勉強会について、どのように進めたか、さらに外部からのスペシャル講師を招いた会について書こうと思います。
この記事が気に入ったらサポートをしてみませんか？