Railsで考えるドメイン駆動設計のコアドメイン

by MinoDriven

Slide 1

Slide 1 text

Railsで考えるドメイン駆動設計のコアドメイン 2020/10/23(金) 銀座Rails#26 ミノ駆動 (@MinoDriven)

Slide 2

Slide 2 text

アジェンダ ● 自己紹介 ● 本スピーチの目的 ● ドメイン駆動設計の「ドメイン」とは ● コアドメインとは ● コアドメインの価値向上手法 ● DDD実現手段とRailsへの応用、その考え方 ● 巨大Railsレガシーの技術的負債にDDDで立ち向かった例 ● DDD向き不向き ● まとめ

Slide 3

Slide 3 text

自己紹介 ● ミノ駆動（@MinoDriven） ● リファクタリング大好き。 ● クソコードを滅ぼす技術が大好き。 ● たまに夢の中でもリファクタリング… ● ㈱クラウドワークスではリファクタリングや設計が主任務。 ● 巨大Railsレガシーの技術的負債に対し、DDDベースにリファクタリング実践中。

Slide 4

Slide 4 text

職歴 1社目　㈱NECネットワーク・センサ：ファームウェア、電子回路設計 2社目　キヤノン㈱：医療X線撮像ソフトウェア、工場監視用画像処理サーバの開発、リファクタリング 3社目現職　㈱クラウドワークス：「自社のRailsレガシーがヤバいのでリファクタリングしてほしい」とTwitter上でナンパされ入社 ● C#を十数年、その他CやC++で組み込みやWindowsネイティブの開発経験が長いです。 ● Web系はまだ1年半ほど。Rails含めてWeb周辺技術は全然浅いです。

Slide 5

Slide 5 text

Qiita

Slide 6

Slide 6 text

クソコード動画

Slide 7

Slide 7 text

バグ退治RPG「バグハンター2 Reboot」制作中

Slide 8

Slide 8 text

ドメイン駆動設計とはエリック・エヴァンス氏が考案した設計手法。ドメインモデルのモデリングを中心に、ソフトウェア開発に伴う複雑さを解決する。長期的な開発力向上に威力を発揮すると言われている。特にマイクロサービス化ではほぼほぼセットで語られる。

Slide 9

Slide 9 text

ドメイン駆動設計に対するイメージなんだか難しそう… 設計パターン集？ Railsでは無理アカデミックな理論で実用性なし机上の空論

Slide 10

Slide 10 text

RailsではDDDは難しい？お互いの良さを殺してしまう Rails-wayから外れてしまう DDDやりたいならはじめから Rails使うな型がなくてつらい

Slide 11

Slide 11 text

ちょっと待てコアドメインはどこに行った

Slide 12

Slide 12 text

コアドメインが語られない違和感 DDDを採用するかどうかとか、RailsでDDDは困難とか議論する以前に、そもそもDDDのコアドメインが議論されているのをあまり見聞きしたことがない。 DDDではコアドメインが真の主人公なのに！！

Slide 13

Slide 13 text

軸がなくフワフワと漂う議論何のためにDDDで設計するか、その議論はコアドメインを意識することが必須。しかしコアドメインがすっぽ抜けているために、DDDは「設計パターン集なんでしょ」とか「アーキテクチャが合わないから無理」とか（私から見ると）いまいち議論の軸が定まっていないように見える。

Slide 14

Slide 14 text

目的そこで本日はDDDの真の主人公コアドメインを中心に、ドメイン駆動設計で解決したいことの理解を目的とします。その上で、RailsとDDDとの関係や、どう応用するかについて考えるキッカケを皆様にご提供することを目的とします。

Slide 15

Slide 15 text

まずはRailsから離れてソフトウェア開発全般の事柄として聞いて下さい。 (※あとでRailsの話をします)

Slide 16

Slide 16 text

DDD序文 DDD序文より引用。いの一番でコアドメインが登場している。「境界付けられたコンテキスト」や「ユビキタス言語」は頻繁に議論されるが、どういうわけかコアドメインだけが空気扱い。

Slide 17

Slide 17 text

「コアドメイン」って何よ？ …の前に、ドメイン駆動設計の「ドメイン」とは。

Slide 18

Slide 18 text

ドメイン（問題領域）： RPGを楽しみたい解決領域：ドラゴンクエスト解決領域：ファイナルファンタジーメラメラミファイアメラゾーマファイラファイガドメインモデル： ActiveRecordではない。ドメインの課題を解決するモデルであり、物事の特定の側面を抽象化したもの。ドメイン課題を効果的に解決するための変換能力を備えた概念。変換能力がなければドメインモデルとは呼べない。

Slide 19

Slide 19 text

問題領域： RPGを楽しみたい様々な戦い方、成長を楽しみたいアイテムコンプしたい魔法で戦いたい解決領域：ドラゴンクエスト武闘家バイキルト小さなメダル盗賊賢者ニフラムメドローアドメインには、さらに個々のドメイン（問題領域）がある。各問題領域の解決に貢献するドメインモデルがいる。

Slide 20

Slide 20 text

問題領域： SNSを楽しみたい情報収集話題性コンテンツ健全性解決領域： Twitter ブックマークミュートリツイートモーメントリストブロック通報 Twitterの例いいねフォロー

Slide 21

Slide 21 text

皆さんそれぞれが開発しているサービスのドメインやドメインモデルを考えてみましょう。個々の問題領域を思い浮かべましょう。

Slide 22

Slide 22 text

イメージできました？

Slide 23

Slide 23 text

…と、ここでいきなり経営者視点

Slide 24

Slide 24 text

どこに開発リソースを投じるか？開発リソースは有限です。限られた予算、時間、人材の中で、開発に投資しなければいけません。サービスには対象とする問題領域が様々あります。どこの問題領域に投資すれば顧客の課題を解決し、顧客に訴求し、大きく利益を得られるでしょうか？

Slide 25

Slide 25 text

どこが費用対効果が高い？あのニーズ？それとも別の顧客課題？

Slide 26

Slide 26 text

あなたのサービスのウリは何ですか？

Slide 27

Slide 27 text

それこそがコアドメイン

Slide 28

Slide 28 text

コアドメインとはシステム内で最大の価値を付加すべき場所。価値があり重要で、費用対効果が最大の箇所。競争優位性があり、差別化が図られ、ビジネス上優位に立つポイント。優位に立つため設計の一部を秘密にしておく場合もある。コアドメインの名の通り、ビジネスの中心的な問題領域。問題領域コアドメイン汎用サブドメイン支援サブドメイン

Slide 29

Slide 29 text

自分たちのサービスがいまいち顧客に訴求しない …。折角開発したのに顧客にウケない…。利益が上がらない。自分たちのサービスのウリは分かっている。もっとウケるように次々新しい仕様を盛り込みたい。でもウリの部分がクソコードすぎて、スピーディーに開発できない…。開発コストだけがいたずらに増大する。こんな課題を解決するのがドメイン駆動設計。

Slide 30

Slide 30 text

ドメイン駆動設計の目的ドメイン駆動設計は、コアドメインについて、以下2点の継続的な向上を目指し、サービスを継続的に利益体質にする設計思想である。ビジネス価値：コアドメインのビジネス価値を向上し、顧客に訴求し（つまりバカウケし）、サービス利益の最大化を図る。開発生産性：コアドメインを構成するモジュールの変更容易性を高め、低コストでスピーディーにコアドメインの価値を向上する。

Slide 31

Slide 31 text

有名サービスのコアドメインは何かを考えてみる ※登壇者の私見、解釈であり、実際とは違う可能性が多分にあります

Slide 32

Slide 32 text

Twitter のコアドメインは？

Slide 33

Slide 33 text

問題領域： SNSを楽しみたい情報収集話題性コンテンツ健全性解決領域： Twitter ブックマークミュートリツイートモーメントリストブロック通報いいねフォロー話題性に貢献する、他にはない非常に特徴的なモデルおそらくコアドメイン

Slide 34

Slide 34 text

リングフィットアドベンチャーのコアドメインは？

Slide 35

Slide 35 text

問題領域：フィットネスゲームを楽しみたい飽きずに続けたい解決領域：リングフィットアドベンチャーリング君フィットスキルステージギミックプレイヤーの運動動作をモンスターへの攻撃に変換する非常に画期的なモデルおそらくコアドメイン (開発者インタビューの内容より ) アドバイザであり、心理的にサポートするメンター道中の様々なギミックの正体は、動的なフィットネスメニュー。

Slide 36

Slide 36 text

なぜコアドメインとそれ以外を区別するか開発リソースが有限だから。費用対効果を最大化したいから。サービスが巨大化してくると、サービスの中心的な価値が何であるか、だんだん分からなくなってくる。費用対効果を高め、差別化を図って競争優位性を得るには、何が自分たちの中心的価値かを理解するのが肝要。サブ的要素や的外れな要素に投資してもリターンは薄い。著者エヴァンス氏「手の込んだ設計を、あらゆる詳細への適用を推奨しているわけではない。重要な箇所に集中する」（意訳「全部DDDでやれとは言ってない」

Slide 37

Slide 37 text

エヴァンスさんが考案したコアドメイン価値向上の手法

Slide 38

Slide 38 text

①ビジネス価値向上に関連する手法（一部抜粋）手法説明ドメインエキスパート問題領域に関して深い知識を持つメンバー。ドメインビジョン声明文コアドメインの価値を簡潔に説明した文書。深いモデルコアドメインの本質的課題の解決に大きく貢献する、重要モデル。暗黙的概念本質理解に重要だが、明示的に示されない隠れた概念。ユビキタス言語ビジネス概念を噛み砕き、ソフトウェアが解決したい本質的概念を理解するための言語。顧客のニーズに訴求し利益を増大するには、顧客課題の本質を理解し、その本質的課題を解決するドメインモデルを発見・発明・改良しなければならない。フィットスキルリツイートコアドメインと同様にドメインモデルの価値向上も DDDの議論であまり語られない！でも超重要！！

Slide 39

Slide 39 text

②開発生産性向上に関連する手法（一部抜粋）手法説明ユビキタス言語関係者全員の意思疎通の精度とコストパフォーマンス向上に貢献。ドメイン層 UIやDBなど他の技術レイヤから隔離され、問題領域の課題解決に貢献するピュアな層。コアドメインの構成要素を他から隔離する。 Repository 永続化ロジックをドメインロジックから隔離する設計パターン。 ValueObject 値の振る舞いを表現する、 DDDで基本にして重要なパターン。コアドメインを解決するロジックが低凝集密結合なクソコードになっていると、折角ビジネスチャンスがあってもすぐに変更できず、市場要求に素早く対応できなくなる。また、コアドメインに貢献する概念（ドメインモデル）に相当するロジックを発見したり、改良するのが困難になる（やりたいことはむしろコレ）。だから以下各種設計手法を用い、コアドメインのロジックをクリーンな構造にして開発生産性を向上させなければならない。

Slide 40

Slide 40 text

ここで唐突に質問です

Slide 41

Slide 41 text

世の中には様々なサービスがあります。どのサービスにも、それぞれウリになる部分があります。つまり、コアドメインが存在します。

Slide 42

Slide 42 text

でもどのサービスがRails製で、どのサービスが非 Rails製か、パッと見で見分けがつきますか？

Slide 43

Slide 43 text

JavaだからSpringBootだからコアドメインがある、 Railsだからコアドメインがない、ではないはず。それらは実装方法の違いに過ぎません。ゆえにRailsアプリにも、対象とするコアドメインがあります。

Slide 44

Slide 44 text

サービスのウリになる部分を把握していますか？

Slide 45

Slide 45 text

ウリの部分の設計はクリーンですか？高い開発生産性を出せる、変更コストが低い設計になっていますか？

Slide 46

Slide 46 text

View Controller ActiveRecord ActiveRecord ActiveRecord ：重要ビジネスロジック重要ビジネスロジックがあちこちに散在している。そのため、サービスの中心的価値が何なのか、ロジックレベルで認識困難な状態。関係し合う重要ロジックや影響範囲を探し回らないといけないため、高い開発生産性を出せない。

Slide 47

Slide 47 text

View Controller ActiveRecord Domain ActiveRecord ActiveRecord ：重要ビジネスロジック重要ビジネスロジックをドメイン層に凝集。他の関心事（例えばUI制御やDB制御）から隔離する。サービスの中心的価値を認識しやすくなる。関係し合う重要ロジックがドメイン層内で整理されていることで高い開発生産性を出せる。注文予約割引金額クリスマスキャンペーン特別会員価格

Slide 48

Slide 48 text

View Controller ActiveRecord ActiveRecord ：重要ビジネスロジック Rails新規開発では始めから何をウリにするか狙いを立ててるから、そもそもコアドメインを喪失していない。コアドメインを解決する重要ロジックが散らばっていることもないから、 DDDでやる価値が薄い。そもそもRails-wayに乗る利点が薄れてしまう。

Slide 49

Slide 49 text

DDD実現手段に関するエヴァンス氏の見解 DDDはコアドメインの価値を高めるため、コアドメインを構成するロジックをドメイン層へ隔離し、ドメインモデルをドメインオブジェクトとして設計実装するのを実現の主眼としている。実現手段は、オブジェクト指向言語がやりやすい、と言ってるだけで、それ以外じゃダメだとは言ってない。手続き型言語でも限定的には可能。 DDDに登場するパターン以外にも、GoFのデザインパターンで使えるものが様々あり、活用できることは素晴らしい、と述べている。

Slide 50

Slide 50 text

DDD実現手段を巡る解釈 Aggregate、ValueObjectなど、DDDで紹介されているパターンは、「こうすればDDDを実現しやすい」とエヴァンス氏が考案した手段のひとつに過ぎない。先の手続き型言語やGoFに対する見解も加味すると、Rails流のDDD実現手段が編み出されてもいいのでは？と考える。

Slide 51

Slide 51 text

エヴァンス氏に関係なく我々がどう設計するかエヴァンス氏はエンジニアの一人であり、何が何でも彼の設計方針通り全て従わなければならない理由はない。設計界隈では、DDDに関してより実用的に改善する動きがある。例えばユースケース層を設けたり(※1)、「ドメインじゃ分かりにくいから『人の営み』と呼称しよう(※2)」など。 ※1：松岡幸一郎氏( @little_hand_s )「ドメイン駆動設計モデリング/実装ガイド」( https://booth.pm/ja/items/1835632 ) ※2：林宏勝氏( @hirodragon112 )「概念投影によるオブジェクト指向設計の考え方とその方法」 ( https://speakerdeck.com/hirodragon112/conceptual-projection-design )

Slide 52

Slide 52 text

エヴァンス氏に関係なく我々がどう設計するか RailsにはDBに依存しないActiveModelや、ValueObjectを実現するcomposed_ofなど、ビジネスロジックを凝集する独自のエコシステムがある。従ってRailsならではの方法でコアドメインを構成する手段があってもいいのでは、と考える。もう一度おさらい。DDDの目的は、コアドメイン（中心的問題領域）を解決するロジックのビジネス価値向上（収益最大化）と、開発生産性の向上（開発コスト低減）である。この目的を達成できれば、極論手段は何でもいいはず。鵜呑みにしてはいけない。立ち止まってはいけない。我々は技術での課題解決を生業とするエンジニアである。

Slide 53

Slide 53 text

巨大Railsレガシーの技術的負債にDDDで対処ドメイン層を追加。ビジネスロジックをドメイン層へ凝集するリファクタリングを実施。詳細はQiitaの「ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ！！！」 (https://qiita.com/MinoDriven/items/3c7db287 e2c66f36589a)

Slide 54

Slide 54 text

良かったこと技術的負債の解消に貢献(Code Climate)。ドメイン層へ凝集したコードが異常に追跡しやすくなった。永続化など他の関心事とは隔離され、混乱が低減。リファクタリングの途中で、それまで隠れていたビジネス概念を発見。隠れた仕様の掘り起こしに成功。設計未経験の新人にレクチャーしながらリファクタリング。わずか3ヶ月でOOPの利点を踏まえた設計提案や、同じ目線でDDDを議論できるレベルにアップ。

Slide 55

Slide 55 text

辛いこと ActiveRecordからニョキニョキ生えてくるbuild_xxxやcreate_xxx。ヤツがいるせいで影響範囲の把握が困難。 callback地獄。after_saveで他のモデルをupdateしてると変更追跡が困難。静的型付け言語ならIDEで参照検索できるのに、検索手段がgrepとか苦悶。名前がカブると詰む。ユニークな命名必須。 ViewとActiveRecordの密結合が最凶の敵。Railsは結合度を犠牲にスタートアップ加速力を得た犠牲的アーキテクチャ。この密結合の影響でバックエンドの負債解消も困難になっている箇所がある。 Rails-wayから外れるのは相当な苦行であることに違いはない。

Slide 56

Slide 56 text

DDDの向き不向き DDDは、サービスのライフサイクル全体を通じて継続的に価値向上目指す、長期開発力を主眼にしている。そのため、プロトタイプなど短命のソフトウェアや、コード変更されない寿命間近のサービスには適さない。コストがかかるだけ。 DDDの実践にはビジネス理解が必須。なぜならドメインモデリングにはビジネス理解が必須だから。「私は技術には興味ありますけど、ビジネスには興味ありません。仕様はビジネス側で考えて下さい」といった考えをお持ちなら厳しい。DDDを実践したいならビジネス課題に目を向けましょう。（尺の問題上この資料では説明しないが）また、DDDに関係なく、ビジネスの理解は単一責任原則を遵守した設計に貢献する（むしろ必須）。

Slide 57

Slide 57 text

DDDの向き不向きドメインモデルの継続的な価値向上のため、継続的にリファクタリングしていく必要がある。静的型付け言語ではIDEなどの静的解析機能により、リファクタリングの正確性、速度の面において有利。一方Rubyなど動的型付け言語では静的解析の精度が落ちてしまい、速く正確にリファクタリングを回していけないため、DDDに不向きとは言えないまでも、課題感がある。

Slide 58

Slide 58 text

まとめサービスには中心的価値となるコアドメインがある。ドメイン駆動設計は、コアドメインのビジネス価値と開発生産性を継続的に向上させる設計手法である。 DDDではドメイン層を用意し、コアドメインを解決する重要ビジネスロジックをドメイン層へ実装し、他と隔離するのが特徴。

Slide 59

Slide 59 text

まとめ DDDではドメイン層を用意する構造ゆえ、Rails新規開発でのDDDは全くオススメできない。Rails-wayから外れ、苦しくなる。しかしDDDの何もかもがRailsに貢献できない、というのは違う。極端。巨大化したRailsレガシーサービスの技術的負債解消や、喪失したコアドメインを捜索する上でDDDの考え方やアプローチは大きな手助けになる。その場合、DDD本書に記載の「エヴァンス流」設計手法をそのまま鵜呑みにしてRailsへ適用するのは課題がある。Railsならではのやり方へテーラリングしたり、よりよい設計方法を模索することが何よりも大事。