クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

既存プロダクトへのドメイン駆動設計の導入検討について

こんにちは!

はじめまして、クラウドログ開発チームで主にバックエンドを担当しているエンジニアの武田です。

クラウドワークスへの入社は2022年の2月で、現時点で約4ヶ月程経ちました。 常に新しい事へのチャレンジしながら毎日を過ごしているため、「あれ、まだ4ヶ月…」という感覚です。
今回はそんな日々のチャレンジを欠かさないクラウドログ開発チームから今後のチャレンジの一部をご紹介したいと思います。

現在、クラウドログ開発チームでは既存プロダクトへのドメイン駆動設計の導入検討をしています。 その中で私が考えている「課題」や「検討しているアプローチ」について、想いのままに書いてみたいと思います。 お付き合い頂ければ幸いです。

目次

ドメイン駆動設計

ドメイン駆動設計とは

ドメイン駆動設計という名の通り、「価値のある知識」(ドメイン)を中心に設計する手法です。
詳細についてはこちらを参照して頂ければいただければと思います。
(実践がメインですが、基本知識関連へのリンクが多数あります。).

qiita.com

この設計方法は 「価値のある知識」を「一定のルール」に従って「ソフトウエア上で表現」すること を目的の1つとしています。 ここでいう「価値のある知識」というものは、しっかりと整理された業務知識・概念だと思って頂ければ分かりやすいのではないかと思います。
特に「価値のある知識」は大事な要素で、これを1つ1つ定義していくことそこの設計手法の最大のメリットです。

ドメイン駆動設計はコーディング上ではオブジェクト指向の延長ではありますが、「設計」と名のつくようにコードに落とし込むまでの「分析フェーズ」(業務分析・ユビキタス言語の策定・境界づけられたコンテキストの定義等)が非常に大切 です。

関連知識について

ドメイン駆動設計を実践するにあたって必要と思われる技術知識を一覧化してみました。

導入するメリット

  • チーム内でユビキタス言語と呼ばれる「共通言語」での会話が可能となる
  • コードから業務知識を容易に読み取ることが可能となる
  • コードから業務の違和感や課題への気づきが生まれやすくなる

ドメイン駆動設計を導入するメリットについても一覧化してみました。
「共通言語」とは関係者間のコミュニケーション上で同じ概念を指すための言葉です。 この場合の関係者とは、利用者・PO・営業・開発者等のプロダクトのあらゆる関係者を指します。

また、挙げたメリットすべてに共通していることは、垣根をなくすという点です。
「ビジネスサイドと開発サイドの言語の差異をなくす」「コードで業務を再現する」等により、チーム全体が同じ共通言語・知識を持つことが可能となり、決断力の向上・業務のさらなる理解(課題や改善含む)に繋がります。

これまでの取り組み

これまでドメイン駆動設計の導入のため、下記のような取り組みを行ってきました。

特に「ドメインモデリングを活用して一部機能の実装」は私の担当機能(新機能)で行いました。
具体的には検討されていたドメインモデリングを元に、ドメインを中心とする依存関係に整理した上でドメインモデルにロジックを凝縮させる対応を入れています。 これによりドメインモデルに対するユニットテストが描きやすくなったため、不具合対応の工数削減に繋がりました。

またロジックがドメインモデルに凝縮されることで責務が明確になり可読性向上にも繋がりました。

このような取り組みがドメイン駆動設計の本格的な導入検討を行うモチベーションに繋がっています。 ただし、本格的な導入を行うためにはまだ多くの課題があると感じています。

既存プロダクトへの適用する際の課題

ドメイン駆動設計の基本は価値のある知識を探求する ことです。
そのため、既存プロダクトへ適用するにはこのギャップを上手く埋める必要があります。 具体的にはいくつかの課題が発生し、それぞれにアプローチしながら解決していく必要があると考えています。

ここでは「課題」と「検討しているアプローチ」をご紹介したいと思います

課題1. ドメイン駆動設計についての知識共有とチームの合意が必要

課題

ドメイン駆動設計は設計手法であり、ビジネスサイド・開発サイド共にこれらについての知識をある程度共有する必要があります。コストに対してのメリットを提示する必要もあります。

検討しているアプローチ

現状のチームの課題とドメイン駆動設計のメリットを紐付け、まずは小さな検証レベルでの導入の合意を行います。 その検証結果を元に本格的な導入と運用について議論を行い、進めていくのが良いと考えています。

ドメイン駆動設計は中途半端な導入が難しく、導入の成否がはっきりと実感できると思っています。 チームで運用が可能かどうかについても、実際の検証を元に議論するのが良いと考えています。 クラウドログ開発チームでは一部の境界づけられたコンテキストに対して導入を行い、これを小さな検証として知識共有と議論を進めていく予定です。

課題2.「価値のある知識」が明確化・言語化されていない

課題

話者によって使用する言葉が異なり、UI・ヘルプ・開発ドキュメント等においての「表記揺れ」や「複雑なユースケースにおいての認識齟齬」が発生する可能性があります。
特に開発者はコード上のオブジェクト名やDBのカラム名で会話することが多々あります。

検討しているアプローチ

「共通言語」を策定することで、これらの問題を解決できます。
ただし、「共通言語」の策定は単に行えば良いものというわけではなく、いくつかの分析図(ユースケース図やドメインモデル図等)を用いてモデリングし、ビジネスサイド・開発サイド共に合意の上で決定される必要があります。 あらゆる関係者が使用する言語のため、一度決めてしまうと容易に変更できないため注意が必要となります。

こちらは開発チームで一部の境界づけられたコンテキストに対しての「共通言語」の暫定的な策定を行い、関係者交えて認識合わせを行うこと試みようと考えています。

課題3. 「価値のある知識」がコード上に散らばっている

課題

「価値のある知識」として情報がまとまっておらず、データや関数に分かれて点在している状態です。 既存のコードの分析が不十分な場合に、新規コードへの置き換えを行なってしまう

検討しているアプローチ

生半可なリファクタリングでは中途半端に適用されてしまい、逆効果になってしまうケースがあるのではないかという懸念があります。 「価値のある知識」を明確化・言語化し、「境界づけられたコンテキスト」単位で既存のコードからのリファクタリングが有効だと考えています。 リファクタリング対象をカバーするようなユニットテストを実装しておくことで、既存の動きを担保することででき、安全に「境界づけられたコンテキスト」単位でのリファクタリングを行うことが可能です。

また、既存のコードを「価値のある知識」へ移動・リファクタリングを繰り返しユニットテストを通すことで、表面化されていない情報の差異に気付きにも繋がると考えており、これらの方法でアプローチしようと思っています。

まとめ

以上、私が考えている「課題」や「検討しているアプローチ」でした。

頭の中の検討を言語化したものなので不純物が多いと思います。 クラウドログではまだまだドメイン駆動設計の導入を検討しようという段階です。
次回ブログを書く際にはこの机上の空論を実践してみてどの点を苦労したか、実際とどう異なったのか等、ご紹介できればと思います。

最近はドメイン駆動設計関連の書籍や勉強会も多く、実践的な知識を得やすい環境となってきていると思います。 「ドメイン駆動設計?なんか凄そう」と思って、流行りに乗って学習を始めたが「わからん」となる方も多いかと思いました。(自分もその一人です。)
もしこの記事をきっかけにドメイン駆動設計という手法に興味を持って頂ければ嬉しいなと思います。

We're hiring!

クラウドログではドメイン駆動設計へのチャレンジを始め、様々な技術的な課題へ一緒に立ち向かってくれるメンバーを募集しています!! 「技術的な課題」と聞くとワクワクしてしまうアナタ!是非とも一度カジュアルにお話ししてみませんか??

下記のポジションも募集しています。

  • SRE
  • フロントエンドのリードエンジニア

crowdworks.co.jp

© 2016 CrowdWorks, Inc., All rights reserved.