みなさん、こんにちは！プロダクト開発部の吉川（@yoshiyu0922）です。
現在、JMDCが保有している医療ビッグデータを活用して生活者や医療に新しい価値を提供する新規プロダクト開発チームのバックエンドを担当しております。
以前に新規プロダクト開発で採用している技術や設計についてこちらの記事で紹介しましたが、Go x GraphQL x DDDでプロダクト開発をしています。今回はプロダクトの開発が一区切りしてこれからリリースするということで、開発してみて良かったことやこうすれば良かったことを振り返りをしました。振り返りの内容は主にDDDに関することです。
DDDとは
DDDとは「Domain-Driven Design」の略語でドメイン駆動設計と呼ばれるソフトウェア開発手法の一つです。問題を解決しようとする領域（ドメイン）をモデリングによってソフトウェアの設計や実装に反映させることで、ソフトウェアの価値を高めていきます。ビジネスを中心とした開発ができることが特徴の一つです。
採用したアーキテクチャ
DDDのアーキテクチャはレイヤードアーキテクチャやオニオンアーキテクチャなど様々なアーキテクチャがありますが、今回はクリーンアーキテクチャを採用しました。
クリーンアーキテクチャを採用した理由は以下の通りです。
- 他のアーキテクチャと比べてレイヤーを細かく定義でき、各レイヤーの責務がシンプルになる
- レイヤーの責務が細分化されていることで機能の改修や不具合対応によるコードの改修の変更範囲を抑えられる
良かったこと
メンテナンスがしやすい
クリーンアーキテクチャの実装コストは高めだと感じましたが、可読性が良く、メンテナンスがしやすいと感じました。ドメインロジックはEntity、ビジネスロジックはUsecaseをみることで仕様を把握しやすくなっています。
また、一通り実装が完了した後にQAを実施したのですが、不具合の修正範囲を小さくすることができました。開発途中はDDDのメリットをあまり感じない場合もありますが、開発が完了した後はメンテナンスのしやすさを十分に実感し、メンバーからも不具合の改修がしやすかったと言ってもらえました。
軽量DDDから導入しても効果はある
軽量DDDはアンチパターンと聞くことはありますが、個人的には軽量DDDから導入しても効果は発揮できると思いました。DDDを導入しようとすると、学習コストが高くてドメインエキスパートがいない等、実装する前段階でさまざまな課題がありました。
そこで、私は軽量DDDから導入し、DDDの理解を深めながら改善していく方針で進めてみましたが、「可読性が高く、メンテナンスがしやすい」を実感することができました。ドメインモデルは変化していくものであり、継続して改善していく必要があると考えています。
DDDを導入する際には、軽量DDDから導入して徐々に改善していくやり方も選択肢の一つとして検討してみてはいかがでしょうか。
DDDの輪読会を実施して継続的に改善できた
継続してドメインモデルを改善していくものだと言いましたが、それを実現するためにはチームのスキルアップが大切だと考えています。ですので、DDDに関する本の輪読会を実施しました。DDD初心者でも理解できる内容で説明がわかりやすいと感じた「ドメイン駆動設計 モデリング/実装ガイド」という本で輪読会を実施しました。
輪読会を通じてDDDの知見を身につけ、開発しながらリファクタリングすることでメンバーのスキルアップとコード品質の向上が実現できたと考えています。勉強会をしながらプロダクト開発をすることで学んだことをすぐに開発に活かせる状況がとても良かったと感じています。
こうすれば良かったこと
プルリクエストが大きくなりがち
レイヤーが細分化されているため、プルリクエスト（以下、PR）を作成するときにレビューしてもらうファイル数が多くなる傾向がありました。さらに全てのレイヤーでテストケースを書く方針にしているため、APIを1から実装したPRは大きくなってしまいました。
そのため、PRの粒度を検討する必要がありました。例えば、レイヤーごとにPRを作成したり、実装とテストケースを分けてPRを作成したり試行錯誤で試してみました。現在は実装とテストケースを分けてPRを作成する方針が今のところ現実的かなと考えていますが、PRの粒度はもっと良い方法があると思いますので引き続き模索中です。
ドメインモデル図は最初から作った方が良い
今回の開発ではドメインモデルがシンプルであり、ドメインモデル図を作成せずにメンバーと認識合わせしながら開発していきました。その結果、同じようなドメインができてしまい、全体のドメインモデルの把握がしづらくなってしまいました。例えば、ユーザと問診の2つのEntityがあったときに、SQLでユーザと問診をjoinした結果からユーザと問診のEntityをインスタンス化するのではなく、ユーザWith問診というEntityを新しく作成してインスタンス化するというような実装を一部してしまいました。
そのため、ユースケース図とドメインモデル図を作成して、ドメインモデル図とドメインの実装をマッピングできるようにドメインモデルをリファクタリングしました。ユースケース図とドメインモデル図を作成することでドメインモデルをチームで認識合わせができ、ドメインモデル図と実装をマッピングさせることで新しくメンバーがジョインしてもスムーズに理解ができると考えています。
まとめ
他にも良かったことやこうすれば良かったことはありますが、改めてクリーンアーキテクチャを採用して良かったと感じています。
「輪読会を実施しながらプロダクトを開発する」ということが継続的にできたことがチームのスキルの底上げに貢献できたと感じました。品質が良くなっていくことが実感できて良かったです。今後もチームのDDDのスキルを高める取り組みを実施して長く運用でき、高速にスケールできるプロダクト開発ができるように頑張っていこうと思います！
また、プロダクト開発部では輪読会を開催したりGoのオンボーディング環境を整えたりスキルアップの環境づくりに取り組んでいます。そのことに関しては別の機会に詳しく紹介しようと思います。
終わりに
JMDCでは新規プロダクト開発のバックエンドエンジニアを募集しております！ ヘルスケア領域の課題解決に一緒に取り組んでいただける方、ぜひこちらをご覧ください。 加えて、私の所属している新規プロダクト開発チームのバックエンド以外にも、EM/フロントエンド /バックエンド/ データベースエンジニア等、様々なポジションで募集をしています。詳細は下記の募集一覧からご確認ください。
Webサービス開発・運用に興味がある方はこちら
基幹・業務システム開発・運用に興味がある方はこちら
まずはカジュアルにJMDCメンバーと話してみたい／経験が活かせそうなポジションの話を聞いてみたい等ございましたら、下記よりエントリーいただけますと幸いです。
★最新記事のお知らせはぜひTwitterをご覧ください！
