こんにちは、CTOの
id:motemenです。
もうずいぶん昔のことになるんですが、掲題のとおり『Domain Modeling Made Functional（邦題 関数型ドメインモデリング）』の社内読書会を開催したので、簡単にまとめてみようと思います。
ちなみにどのくらい昔のことかというと、邦訳版の発売が発表される前に読書会をはじめていたので、じつに一年半ほど昔のことになります……。
動機
はてな社内のエンジニア職種組織には、チームを越えて特定の技術分野について知見共有や横断する課題に取り組むサブ会や、全エンジニアが参加する技術勉強会などさまざまな取り組みがあり、こういった場を通じてエンジニアの成長を支援しています。この仕組み自体はうまく回っているのですが、中期的な技術力の向上を考えたとき、具体的な技術について学ぶことはできるものの、より抽象的なソフトウェアの設計といったトピックについて学ぶ機会を提供できていないのがひとつの課題でした。
個人的には『実践DDD』でエンジニアとして成長できた実感もあり、同じような体験を提供できればと考えていたところ、前に読んでよい印象を持っていた『Domain Modeling Made Functional』なら、同じようにドメイン駆動設計を学びながら、静的型による表現方法も学ぶことができて好都合だったためこちらの読書会への参加を呼びかけました。結局30人ほどが参加してくれたようです。
Go・TypeScript・Scala チームに分かれて輪読
章ごとに当番を決めて発表する、通常の輪読方式で運用しました。
はてなではGoとTypeScriptをメインの言語として採用しており、これらの言語への練度を高めたかった狙いもあったので、Go・TypeScript・Scalaチームに分かれ、この本で採用されているF#での実装をそれぞれの言語で実装する、という条件にしました。とくにGoで同じように実装するのは現実的ではないのは想像できますが、限界と工夫を知っておくためにも積極的に入れています。
同じ章を3人が読むことになるので、解釈を補完しつつ具体的なコードを比較でき、議論に深みを出すのにも多少は貢献したのではないかと思います。
やってみて
ドメイン駆動設計の共通語彙ができたのはもちろんですが、とくにこの本で紹介されている関数的な考え方、「ワークフローの両端にIOを追い出す」「型によってありえない状態をあらかじめ排除する（Make illegal states unrepresentable）」といった考えは社内でもDMMF的手法として認知され、実際にさまざまチームでの設計やレビューに登場するようになりました。
懸案のGoについてはやはり直和型を直接的に表現するのは難しく、現実的にはinterfaceをうまいこと使っていくことになりますが、それでも先述のように共通の設計語彙があることで、現場においても設計の議論はスムーズに進んでいたように見えます。また、TypeScriptに馴染みのないメンバーもいましたが、型による表現において具体的な実装レベルで知見が得られた、という感想があったのは予想外の収穫でした。
実際に読書会のさなかに新しく設計する機会があり、この本の手法をGoで採用してみたチームの 
id:maku693 からコメントをもらいました:
ちょうどDMMF読書会と前後して、Goで書かれたウェブアプリケーションの新機能を手がける機会があり、読書会で学んだ知見を活かして開発を進めました。
言語機能の違いから、この本のプラクティスの全てを直接Goで実践できたわけではありませんが、コードを書き始める前にドメインを丁寧に理解するように努めることや、型の活用・処理のパイプライン化といった考え方は、複数人での大規模な機能の開発をスムーズに進める助けになったと思います。また、プロジェクトの振り返りでは、チームメンバーから「それ以前のアーキテクチャに比べてドメインロジックの見通しが良くなった」という感想をもらいました。
「Goで具体的にどうやってDMMF本のエッセンスを実現するか」という問題については、これからも探究していきたいと思いますが、言語によらない部分に関しては、自分の知識としてすでに役立っていますし、今後の業務でも積極的に活用していきたいと思っています！
ちょうど記事を投稿する本日（10/31）開催の hatena.go #2 でも、別のチームから具体的な知見を共有できそうです！
ひとつの本をみんなで読むのって楽しいですよね。ちなみに現在は『データ志向アプリケーションデザイン』の読書会が進んでいるようです。
コメント