Pathee engineering blog

世界をしなやかに変えるエンジニアたちのブログ

「レガシーをぶっつぶせ。現場でDDD！」に参加しました。

author:消火器

はじめまして。 春からPatheeでエンジニアをしています、消火器です。

今回はドメイン駆動開発(Domain-driven design、DDD)を学ぶために、参加したレガシーをぶっつぶせ現場でDDD！の参加記になります。

発表の内容自体は各々の発表者様があげてくださっているので、自分が聞いた上での備忘録的まとめと感想を共有させていただければと思います。

genbade-ddd.connpass.com

ソフトウェアの核心にある複雑さに立ち向かう

  • 発表者 : ギルドワークス増田さん
  • 資料 :

www.slideshare.net

内容まとめ

  • ビジネスにおける全ての要素を表現するからこぞソフトウェアは複雑であり、その中でもっとも複雑な核となる部分はビジネスのルール(条件分岐や計算)である
  • そこに対しドメイン駆動開発で挑むためにもっとも重要なことは、ビジネスとモデルの中核に向き合い、言語化していくことである
  • 言語化を繰り返しより良いモデルを作ることことで、変更に強くレガシーに強い開発ができるようになる

「ソフトウェアの複雑さを産むものは、ビジネスルールの計算・分岐処理である」

  • Q.そもそも今のソフトウェアがさまざまな機能やシステムにまたがり複雑なのはなぜか?
    • A.ソフトウェアユーザの行動を定義・再現しようとしているから
      • ユーザの行動、ビジネスの全ての要素 = ドメインである
      • ドメインのソフトウェア的表現 = ドメインロジック
      • ドメインロジックに記述されるような内容は、そのままビジネスにおけるビジネスルールと読み替えられる
        • 以降ドメインロジック = ビジネスルールとする
  • ビジネスルールって実際どんなもの?
    • 数量的データ：金額、数量、期日、場所などの計算と判定
    • 計算・条件分岐：顧客区分、商品種別、地域区分、金額区分、数量区分、取引種類、など
  • 真に複雑なのは、計算・条件分岐である
    • 数量的データは数こそ多く面倒だが、複雑ではない
    • しかし、計算・条件分岐は、複雑になりがち
      • 同じロジックを使いまわせず冗長になったり、使い回し先でインプットが統一されてなかったりすると特に

「ドメイン駆動設計 = ドメイン特化でモデル(型/クラス)設計を行う開発のこと」

  • ユーザの行動、ビジネスの全ての要素 = ドメイン である
  • ドメインがどう構成されているかを分割し定義することを、モデル という
    • 例えば、「本の貸し出しシステム」であれば、「どの【本を】【誰が】借りているか」となる
      • 勿論他の例もあり得る
      • 機能や取り扱うものが増えれば、当然管理するものが増える
        • 例であれば【いつまで貸し出すのか】とか、【返却はすんでいるのか】
    • 名詞と動詞で切り出していくと良いです
    • ちなみにオブジェクト思考に近いです
  • 複雑さの根源 = ドメインロジックであるならば、 ドメインモデル = 複雑なモデルの整理 であり、 オブジェクト指向 = モデル&実装の一部 であると言える

「ドメイン駆動設計で複雑さに挑むために、ビジネスとモデルの中核に対してしっかり向きあう」

  • 上述したようにビジネスルールは複雑である
  • それと向き合うために、関心の分離とモジュール構造の工夫をする
    • 例えば、ビジネスルールを記述するモジュール群を作成し、それをアプリケーションで利用するようにする
      • 機能ごとに分割するのではなく、共通のロジックを利用するようにする
      • 分割すると、ビジネスルールの記述処理が断片化し内容が重複し変更を加えにくくなる
    • そのロジックから入力、出力時の整形を切り離したりするとなおいい
    • ビジネスルールに存在する数値に対してしっかり型を定義して明文化する
  • そして真に複雑さに向き合う上で最も重要なのは、深いモデルを探求することである
    • ここでいう深さと言うのは、ビジネスルールの中核を指す
    • その中核をどう形作るかこそが1番重要であり、そこに集中すべきである
  • 深いモデルは決してすぐには見つからない、が探し出す努力をし続けないといけない
    • 段階的に発見し、改善していく
    • 最初は暗黙的な概念になるが、なんとか言語化する直接できいなければその先のものを言語化して戻ってくる
      • 繰り返し良くしていくことが大切

レガシーシステムからモダンな環境への移行

  • 発表者 : ヤフー 清水さん
  • 資料 :

www.slideshare.net

内容まとめ

  • Yahoo!プレミアムのレガシー改善にDDDで挑んだ話
  • DDDを導入する上で意識していたのは、DDDに対する共通認識の作成と、業務ロジックの具体化
  • 上記を意識してDDDを行なった結果、レガシー改善だけでなく、詳細設計がシンプルになったり、IF定義がしっかりするなどのメリットも出てきた
  • 一方、コストが大きくなること、ビジネスサイドへの理解を得るのが一つの課題である

DDDに挑む背景

  • Yahoo!プレミアムは事業形態の関係もあり、以下のような状態になってしまっていた
    • 入隊会ロジックが複数のケース各々に記述され冗長化
    • サブシステムとDBが直接つながり密結合になっている
  • ここからモダンな環境にシフトすることになった
    • なぜやるのか? = ビジネス案件の対応に時間がかかる
      • もちろん色々理由はるけど1番はここ
  • ビジネスに寄り添ったシステム、継続的な改善がしやすいシステムのためにDDDをやることに

DDDを行うために共通認識と具体化を行った

  • DDDを行いモダン化を行うにあたって、行っていたことは以下だった
  • まずはモダン化に対しての共通認識をつくるためにセミナー受講を行なった
    • 全員が同じ認識を持って話せる状況を作る
  • 次に業務分析を行い、ドメイン設計やモデルに起こす作業を行なった
    • 課金箇所/会員/特典と、業務/責務の2行3列の6項目に業務を分割した
      • この時の業務には運用に関わる部分を、変更頻度別に並べた
      • 対して責務にはビジネスに関わる部分を同じように、変更頻度別に並べた
      • 各々の項目はオーナーシップを取れ、kPIに基づくように分割した
    • 重要なものはしっかり細かく、そうでないものはざっくり行う
      • 影響と更新頻度で分割して注力ポイントを探すこと
  • それらを元に実際のアーキテクチャ設計を行う

DDDを行なって変わったこと

  • IF仕様が自然と整備されていく
    • 責務の定義がされているのが大きい
    • swaggerを用いたドキュメント化
  • 詳細設計がシンプルになる
  • 一方で、コストが大きい
    • そもそも再設計である
    • また、細かい作業の分割を行うので単純に量が増える
      • 複雑さは減る
    • 増加するコストと、それに見合う成果の領域をしっかり意識すること
  • モダン化に際して、ビジネスサイドとのギャップが大きい
    • エンジニアの問題だと思われがち
    • レガシーさが理解されない
    • 長期的な働きかけと課題の認識が大切

終わりに

簡単にですが、参加した勉強会の要点をまとめてみました。

勉強会を通して感じたことは、自分たちのビジネス、コード、考え方などの認識を揃えていくことが、DDDの一番重要な部分であり、その上でドメインモデルを構成していくことが大切なのではと感じました。 参加して終わりではなく、ドメイン駆動開発の考えを社内で広めて、議論等を行いたいと強く感じました。 引き続き、学習を続けたいと思います。 それではおわります、ありがとうございました。