サービス

技能：エンジニア

技能：デザイナー

技能：ビジネス職

技能：バックオフィス

ジャンル

<h2>背景</h2>

<p>ポイントスクラムチームで扱っている古いプロダクトはトランザクションスクリプトで書かれた処理が多く、なぜその処理が必要なのか不明瞭な状態でした。また、処理が書かれたタイミングによって、同じ意味の用語が違う言葉で表現されているところもありました。<br />
それにより既存コードの調査コストが高く付き、改修作業におけるメンバーの負担が多くなっていました。<br />
そこで、電子マネーAPIのリプレイスにドメイン駆動設計を採用することを提案しました。ドメイン駆動設計を採用することで、処理の意味が明瞭になり、統一されたユビキタス言語を元にコード/ドキュメント/会話で使用する用語が統一されることを期待しました。</p>

<h2>どうやってチームに適用したのか</h2>

<p>行ったことは全部で3つです。</p>

<p><img alt="" height="574" src="https://image.dmm-corp.com/sfb4rewu34qqm0lm55cen2bvtlsa" width="800" /></p>

<h3>輪読会の立ち上げ</h3>

<p>チーム内にドメイン駆動設計の経験者がいなかったため、まずはドメイン駆動設計を学びたい人を集めて輪読会を立ち上げました。ちょうどそのタイミングで社内にドメイン駆動設計の勉強会をやりたいとの声が上がっていたので、それに便乗して立ち上げることができました。</p>

<p>輪読会では<a href="https://book.dmm.com/detail/k308aousy00282/" target="_blank"><strong>実践ドメイン駆動設計</strong></a>の読み合わせを継続的に実施しました。<br />
具体的なやり方として、輪読会で行う対象のページを事前に決めておき、<strong>各自が予習をしたうえで集まってディスカッションをする形式</strong>にしました。<br />
また、進行しやすいように事前にファシリテータを決めておき、ファシリテータは本の内容を事前にまとめ、輪読会当日に読み上げるようにしました。<br />
事前に準備をしておくことで集まってただ本を読むだけにならず、分からないところを聞きあうことができ、自分のプロダクトにどう適用できるかなど建設的な意見交換ができたと思います。</p>

<h3>チーム内勉強会で動機づけ</h3>

<p>チームにドメイン駆動設計を布教するためにチーム内勉強会を実施しました。<br />
チーム内勉強会では実践ドメイン駆動設計の内容をベースにドメイン駆動設計の概要、メリットとデメリットを説明し、ドメイン駆動設計に興味を持ってもらうことを目的にしました。<br />
実践ドメイン駆動設計の輪読会をチームで行えれば良かったのですが、該当の本は分厚く内容も濃いため学習コストが高く付きすぎると考えて、それは行いませんでした。</p>

<h3>チームへ浸透させる取り組み</h3>

<p>実際にプロダクトを構築する前に、ユビキタス言語とコンテキストマップのたたき台を作ってチームに提案しました。<br />
これらをチームメンバー全員で揉んだことによって、共通の認識を持って同じ方向を向くことができたと思います。</p>

<p>その時点のユビキタス言語とコンテキストマップに関してチームメンバーの合意が取れたところで、ユビキタス言語を元に優先度の高い機能のクラス設計（ドメインモデル設計）とコーディングを行いました。<br />
実際にドメインモデルをコードにすることでチーム内での意見交換が活発になり、ドメインに関する理解がより深まったと感じています。<br />
コーディングとドメインモデルやユビキタス言語の更新を繰り返すことで、ドメインを意識した開発を進めていくことができたと思います。</p>

<p>さらに、リプレイス案件だったこともあり、<strong>既存システムのロジック分析を行ってドメインの理解を深める活動を実施</strong>しました（ロジック解析パーティと呼んでいます！）。<br />
ロジック解析パーティをチーム全員で行うことにより、ドメインエキスパートでも知らなかった知識を見つけ出すことができ、チーム全体のドメイン知識の底上げになりました。</p>

<h2>適用した結果の考察</h2>

<h3>チーム内インタビュー</h3>

<p>ポイントスクラムチーム内でインタビューをした結果、下記のようなコメントを得られました。</p>

<p><img alt="" height="500" src="https://image.dmm-corp.com/awuxchb7pgsobbkbf826eyfsuu5z" width="800" /></p>

<h3>用語の統一</h3>

<p>ドメイン駆動設計を採用した背景にあった「コード/ドキュメント/会話で使用する用語を統一する」に関して、概ね達成できました。<br />
はじめにユビキタス言語を作成し、開発を進めながら常に更新することで、用語に関する認識違いを防ぐことができました。<br />
しかし、コーディングに集中しているとユビキタス言語の存在を忘れてしまい、コードとユビキタス言語が合わなくなってしまうことがありました。<br />
根本的な解決策ではありませんが、レビューのタイミングでユビキタス言語を意識できているかチーム内で指摘し合える環境にすると良いと思います。</p>

<h3>保守・拡張のしやすさ</h3>

<p>ドメイン駆動設計を適用したことで、ドメインオブジェクトの中に必要なドメインロジックが含まれるようになり、処理の意味が明瞭になりました。それにより開発・保守・拡張のしやすさに関して良い結果になったと思います。<br />
しかし、上手く設計できていないドメインを共通処理にして放置してしまったのは問題でした。<br />
これにより、ドメインに属さない「責務範囲のよく分からないビジネスロジック」が存在する結果になってしまい、開発や保守で混乱を招くことになってしまいました。<br />
理想としては一部の設計をやり直してドメインとして定義するべきでしたが、手が回らずに宙に浮いたまま進めてしまいました。</p>

<h2>困ったこと</h2>

<p>実際にドメイン駆動設計をチームに浸透させる際に困ったことを紹介します。</p>

<h3>ドメイン駆動設計が分からない</h3>

<p>おそらくドメイン駆動設計を初めてプロダクトに適用しようと思うと、ドメイン駆動設計のことがよく分からなくなると思います。<br />
ドメイン駆動設計はフレームワークではないので、正解と言える形がありません。<br />
最初から完璧なものは作れないので、学んだ技術を少しずつ適用して試行錯誤する必要があります。<br />
私見としては<strong>戦略的設計</strong>を試行錯誤してドメインを整理し、<strong>レイヤー間の境界を守ってコーディング</strong>することで、拡張しやすいシステムを作れると考えています。</p>

<h2>まとめ</h2>

<p>以上、ドメイン駆動設計をプロダクトに適用する際にポイントスクラムチームで実施したことを紹介しました。<br />
ドメイン駆動設計はシステムの保守・拡張性を高めるには重要な考え方だと思いますが、採用するまでに高いハードルを感じることがあると思います。<br />
採用するためには周囲の協力が必要不可欠になりますので、周囲の人を巻き込みながら採用する方法を模索してみてください。</p>

<p><br />
&nbsp;</p>


こんにちは！
ペイメントサービス部 ポイントスクラムチームの北澤です。
普段はDMMポイントに関するシステムの開発や保守、ペイメントサービス全体を改善するための共通基盤の開発を行っています。
この記事では、DMMポイントの発行や消費などを行う電子マネーAPIのリプレイスでドメイン駆動設計を採用したお話をします。具体的なアーキテクチャよりも、どうやってチームにドメイン駆動設計を適用させたのかに主眼を置いてお話します。

サービス

技能：エンジニア

技能：デザイナー

技能：ビジネス職

技能：バックオフィス

ジャンル

その他

プロダクトにドメイン駆動設計を適用するために行った3つのこと

シェア