はじめに
こんにちは。logyです。
私は前職で一年と少し、ラクスに入社してから一年間ドメイン駆動設計に関連する開発に関わってきました。
今回は、そこから得られた知見や感想、また、これからドメイン駆動設計を実践する方におすすめの方法について書こうと思います。
感想
ドメイン駆動設計との出会い
私がドメイン駆動設計に出会ったのは、前職での部署異動がきっかけでした。
新しく関わることになるプロジェクトがドメイン駆動設計を採用しており、当然、メンバーになった私もその思想を習得する必要があったのですが、 当時、まだオブジェクト指向ですらあまりしっくりと来ていなかった私にとって、分厚いエヴァンス本*1は解読困難な古文書のようでした。
並行して実践ドメイン駆動設計も読み始めましたが、こちらはまだ幾分わかりやすかった気がします。
そのプロジェクトは所謂業務システムとは少し異なる抽象的な領域をターゲットにしており、ドメイン自体を理解するのも非常に難易度が高かったと思います。
一方で、戦術的設計が至るところで用いられており、今思えば、実践ドメイン駆動設計を辞書代わりにコードリーディングを行うには最高の環境でした。
そんな環境で1年ほど過ごして様々なノウハウを身に着けていきました。
今ではそんなに悪い奴ではないかなと思えるように
ドメイン駆動設計に出会ってから2年以上経った今でも、「完全に理解した」とは到底言えず、むしろ「全くわからない」状態に近いのが正直なところです。
しかし、これまで目にしてきたような、すっかりドメインが流出してしまっており、何度もヒアリングを行い想像を重ねることでやっと理解できるようなあのシステム達も、 ドメイン駆動設計を取り入れれば、もしかしたら救ってあげられるのかも、と思うようになったり、実装を進める際にはこれは果たしてドメインの関心事だろうか、と意識するようになりました。 。
当然ドメイン駆動設計も銀の弾丸ではありませんが、うまく使えば、複雑なシステムに立ち向かうための強力な戦力になってくれるはずです。
知見
なぜドメイン駆動設計は難しく感じられるのか
最近はいろんな記事などで触れられることが多いドメイン駆動設計ですが、その内容もさることながら、よく同時に語られるのがその難しさについてです。 導入を試みたが、難しすぎて駄目だった、思ったような効果が得られなかったといった声をよく耳にします。
なぜこのようなことになってしまうのでしょうか。私は次の3つが大きな原因ではないかと考えています。
原典の重厚さ
その当時の私も同じくこれに心が折られました。 頑張って読み進めてもなかなか頭に入ってこない。
原典で語られている話は抽象的なものが多く、一読しただけでは「じゃあ、どうすれば？」となりがちです。
特に初学者の場合は、実践ドメイン駆動設計から読むことをおすすめします。 最近は他にも初学者向けに日本語で書かれたものがいくつか出ているので、分厚い本に抵抗感のある方はそちらから入っても良いかもしません。
ドメイン駆動設計を学べる書籍について、別のラクスエンジニアがまとめた記事がありますので、こちらもどうぞ。
導入タイミングの難しさ
正直言って、ドメイン駆動設計を導入する際の初期コストは大きいです。 ドメインモデリングを行うコストを払う必要があったり、大量のドメインクラスを作ることで実装コストも膨らみます。 その分、保守コストを削減できるのがメリットなのですが、その効果を実感できるのは、ある程度システムが複雑化してからになるため、 開発初期の段階で導入判断を行うのは難しいのではないでしょうか。
一方で、すでに複雑化してしまったシステムに、徐々にドメイン駆動設計を適用することも、かなり骨の折れる作業となり、導入を妨げている要因といえそうです。
ドメインエキスパートの協力が得られない
ドメイン駆動設計の導入に際して、一番のハードルと言っても良いのではないでしょうか。
ビジネスサイドと開発サイドが肩を並べて隣で仕事をしているような現場であれば、大きな問題にはならないですが、 サイロ化が進んでいる組織では、定期的に時間を割いてもらうのがやっとで、必要なときに十分な協力を得られないことがよくあります。
たとえ、開発サイドがドメイン駆動設計の導入に意気込んでいたとしても、ビジネスサイドの理解が得られず、いつの間にか自然消滅…なんてことにも。 ドメイン駆動設計の文脈から外れてしまうため、このあたりにしておきますが、組織に関する問題は、システム開発につきものです。*2
幸い、ラクスでは、ビジネスサイドはもちろん、実際のユーザーでもあるコーポレート部門の方たちにも積極的に協力いただきながら開発を進めることができています。 非常に恵まれた環境で開発を進められてることに、この場を借りて感謝したいと思います。
ドメインモデルは育てるもの
とりあえずモデリングをやってみたはいいものの、あまりしっくりこなかったり、すぐに実状と合わなくなってしまったという経験をお持ちの方も多いのではないでしょうか。
しかし、そこで諦めてはいけません。むしろそこからモデルを進化させ続けることこそドメイン駆動設計の醍醐味です。 特にプロジェクト初期のように、業務理解が浅いうちは、それ相応のモデルしか作成できないはずです。
しかし、ドメインモデリングを行うことそれ自体が、ドメインへのより深い理解を促し、新たな概念の発見を通じて、既存のモデルをより洗練されたモデルへと進化させます。
自社サービスにおけるドメインの捉え方
ラクスのように自社サービスを開発している現場では、ドメインを分析する際に業務ドメインとはまた違った難しさが存在します。 それはドメインがすぐに変化しやすいという点です。
SaaSの開発では、数多くのお客様に使っていただくため、ある程度、どの現場でも共通する業務をターゲットに開発を行います。 つまり、製品が扱うドメインとしては、特定のお客様のドメインではなく、ある程度、最大公約数的なものをイメージして定義することになります。
すると、「このお客様の現場では正しいけど、別の現場では不適切」となるようなドメイン知識を得ることもあり、製品としてどうあるべきか常に折り合いをつけ続ける必要があります。 サービスが成長し続ける限り、その検討範囲は拡大し、時折自己矛盾を生むこともあるでしょう。
それらを反映したドメインモデルを維持し続けることの大変さは、想像に難くないはずです。 また、これまで存在しなかったような、革新的な機能を提供するサービスでは、そもそも新たなドメインそのものを作り出す作業が必要となるため、これもまた大変な仕事になりそうです。
アーキテクチャには適切なフェーズがある
実践ドメイン駆動設計で触れられているような、CQRS+ESといったアーキテクチャは、複雑なシステムを制御する手段として有効です。 私は実際にこれを採用しているプロジェクトに関わったこともありますが、確かにドメインイベントとイベントソーシングの相性は抜群で、どんな要件にも柔軟に対応できるのではという気持ちにもなりました。 集約の設計を突き詰めると、そのうちCQRS+ESにたどり着くといった話も時折耳にします。
しかし、あくまでそれは、そのプロジェクトがいくつもの検討の末にたどり着いた解決手段の一つであるということを忘れてはいけません。 プロジェクトの初期から「DDDをやるならCQRS+ESで決まりでしょ！」みたいな発想で初めるのは明らかにアンチパターンです。
私が関わったプロジェクトでも、初めからCQRS+ESが採用されていたわけではなく、発展を続けるうちに、いろんなパターンを経てたどり着いた、とのことでした。 RDSの限界やNoSQLの発展がCQRS+ESを生み出したように、別の技術の発展がそのうちまた新たな方式のアーキテクチャを生み、発展させていくのでしょう。
現行のアーキテクチャが将来の発展に耐えられそうにないと判断したとき、課題に応じた解決策を選択できるようにしたいですね。
これからドメイン駆動設計を実践する方へ
初めは軽量DDDからでも良い
所謂、軽量DDDはアンチパターンと言われることが多いですが、個人的には、初めは軽量DDDから導入を進めるのも良い選択だと思います。 というのも、上記で述べたように、ドメイン駆動設計は導入、学習コストが非常に高く付く点がネックです。
そこで、戦術的設計を先に導入することで、徐々に理解を深め、最終的に戦略的設計の適用を目指せば、初期コストを低く抑えつつ導入を進められます。 また、評価の結果、ドメイン駆動設計がプロジェクトに合わないと判断された場合でも、戦術的設計はオブジェクト指向設計の1パターンとしてその先も利用でき、負債になりづらいです。
とはいえ、将来的に戦略的設計を全く採用する気がないのであれば、ドメイン駆動設計の導入はおすすめしません。 様々な記事で触れられているように、戦術的設計はあくまでドメインと向き合うための足掛かりとなる手段であり、最終的にはドメインを通じてソフトウェアの価値を高めることがドメイン駆動設計の目的だからです。
そこで、おすすめしたいのは、次のような導入方法です。
すでにある程度開発が進んでおり、ドメイン知識と技術的負債をコードがたっぷり蓄えているプロジェクト
戦術的設計（軽量DDD）を用いて、既存のコードを整理し、ドメイン知識を抽出する。 DDDに慣れてきたら戦略的設計を適用してみる。
これから立ち上げるプロジェクト
戦略的設計を積極的に適用し、ドメインモデルと共に成長を目指す。
おすすめはユビキタス言語から
仮に戦略的設計を導入することになった場合、まずはユビキタス言語の徹底から始めることをおすすめします。
通常のシステム開発でも、用語集や辞書といったものを用いて用語の統一を図ることが多いですね。
しかし、ユビキタス言語は単なる用語集づくりではありません。 ユビキタス言語の特徴としては、統一した用語を開発者だけでなく、ドメインエキスパートとの会話でも使用する点が挙げられます。
これを徹底することで、仕様とコードの行き来が圧倒的に楽になり、コミュニケーションミスも減ります。
また、ドメインエキスパートと開発者が使用する僅かな用語の違いから、新たなドメイン知識を発見するなど、ドメインのより深い理解に繋がります。 他の戦略的設計である「境界づけられたコンテキスト」の実践にも、ユビキタス言語は非常に重要な役割を果たすため、初めに適用することで後続につなげることもできます。
いかにしてドメイン知識を得るか
もちろんドメインエキスパートとの会話が一番の機会になるでしょう。
仕様の相談はもちろん、そのときは開発と直接関係がないような業務上の話題まで、ドメインエキスパートと同じ目線でドメインを捉えることができるようになればなるほど、 開発はスムーズに進むようになるはずです。
また、ドメインエキスパートが普段触れている情報源に触れてみるのも一つの手段です。 日々のニュースや、必読とされている書籍など、少しでも同じ知識を手に入れることで、普段の会話にもついていきやすくなります。
関連する資格取得を目指すのも良いかもしれません。銀行検定、証券外務員、簿記、社労士など、資格勉強を通じてたくさんのドメイン知識に触れることが出来ます。
最後に
この記事では、私が2年間と少しドメイン駆動設計に関わって得られた、感じたことについてまとめてきました。
ドメイン駆動設計については、多くの方がさまざまな媒体を通じて情報発信されています。 私も色々見聞きはしたものの、まだ実践できていないようなプラクティスもたくさんありますので、引き続き経験を積んでいきたいと思います。
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
rakus.hubspotpagebuilder.comラクスDevelopers登録フォーム
https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/イベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！
◆TECH PLAY
techplay.jp
◆connpass
rakus.connpass.com
