Upgrade to Pro — share decks privately, control downloads, hide ads and more …

導入事例を通じて理解するドメイン駆動設計

kumaGoro95
February 22, 2021
110

 導入事例を通じて理解するドメイン駆動設計

現在、サーバーサイドエンジニアを目指し勉強中です。

先日、「ドメイン駆動設計」をテーマにLT発表を行いましたが、終始抽象的な話になってしまい、自分自身DDDについて理解しきれていませんでした。
今回は、実際の導入事例がまとめられた記事を参照し、導入事例を通じてDDDについて理解しようという試みを行いました。

<参考文献・参照ページ>
「ドメイン駆動設計で保守性をあげたリニューアル事例 〜 ショッピングクーポンの設計紹介」
・『ドメイン駆動設計入門』成瀬 允宣著
レイヤードアーキテクチャの視点
境界付けられたコンテキスト 概念編 - ドメイン駆動設計用語解説

kumaGoro95

February 22, 2021
Tweet

Transcript

  1. 導入事例を通じて理解する
 ドメイン駆動設計
 くまごろー


  2. 今日の流れ
 1.DDDとは何か?(前回のおさらい)
 2.DDDって実際どんなことをやるの?
  (Yahoo!の導入事例を紹介しながら説明)
 3. DDDを導入するとどんな利点があるの?


  3. DDD(ドメイン駆動設計)って何?
 ・現実にある業務(ドメイン)を正しく分析して「ドメインモデル」として表現し、ドメ インモデルを元にコードを作成する設計思想
 ・運用と共にモデルを改善・進化させ続けることで現実の業務とコードの一体化 を進め、運用しやすいアプリケーションを作る

  4. で、実際どうやってやるのか?


  5. Yahoo!でのDDD導入事例
 <導入前>
 ・PHP
 ・モノリス※
 ※ 大きなビジネスロジックで全て の 処理を行う
 <導入後>
 ・Java/SpringBoot
 ・マイクロサービス化
 ※ 参照「ドメイン駆動設計で保守性をあげたリニューアル事例

    〜 ショッピングクーポンの 設計紹 介」

  6. DDD導入の背景
 Yahoo!ショッピングには様々な種類のクーポン
 ・「モールクーポン」(Yahoo!側が発行)
 ・「ストアクーポン」(ストア側が発行)
 それに加え、ユーザー属性・商品カテゴリー等、様々な要素を掛け合わせるこ とが出来る
 → 多様な購買施策を実現できる一方でシステムは複雑に


  7. 今回DDDで刷新された機能 1.ユーザー属性・カゴ内の商品を加味→適用可能クーポンを返却
  (適用機能)
 2.クーポンをカゴ内商品に適用したときの金額を計算(計算機能)
  (クーポンの複数組み合わせ、割引額の商品ごとの案分なども考慮) 
 


  8. DDD導入の手順(Yahoo!事例から) 1.システムの関心事(=モデル)を分析する
 2.レイヤードアーキテクチャによる関心の分離でドメインロジックを 疎結合に する
 3.ドメインモデルを成熟させることで高凝集性を獲得する
 4.リファクタリングの繰り返しでコアドメインを見いだす
 ※ LTでは、1・3・2・4の順で説明


  9. 1.システムの関心事(=モデル)を分析する


  10. キーワード:「関心の分離」 <商品>
 <配送部>
 <販売部>


  11. 配送部にとっての商品・・・ <商品>
 <配送部>
 ・商品名
 ・発送元
 ・配送先
 ・配送状況


  12. 販売部にとっての商品・・・ <商品>
 <販売部>
 ・商品名
 ・型番
 ・売値
 ・在庫数
 → 立場・部署によって「商品」のイメージが全く異なる
 → 一見単一のオブジェクトでも、複数の「関心」を持っている


  13. 特定の関心事に分ける
 <配送コンテキスト>
 <販売コンテキスト>
 ・商品名
 ・発送元
 ・配送先
 ・配送状況
 ・商品名
 ・型番
 ・売値


    ・在庫数
 「コンテキスト境界」と呼 ぶ
 「配送品」
 「在庫品」

  14. 業務領域(ドメイン)の分析(Yahoo!) ・カートチーム、クーポンチームが連携を取り開発
 ・この記事の筆者はクーポンチームに所属
 → まず最初に分析モデル図を作成
 


  15. モデル図から判明したこと ・「カゴ」という概念にあまり触れてこなかったことに気づく
 → 「カゴ」がコンテキスト境界であったことが判明

  16. コンテキスト境界でモデルを分割 ・ クーポンサイドとカートサイドの間に、「Basket」のコンテキスト 境界があっ た
 ・ クーポンサイド内部でも、「Basket」は「適用機能」「計算機能」 で異なる側面 を持つことが判明
 → 「Basket」の機能を「計算」と「適用」に分割し、それぞれでモデ リングする ことに


  17. 2.ドメインモデルを成熟させることで高凝集性 を獲 得する


  18. 1.で分析したモデルを、ドメインモデルとして実装する

  19. ドメインモデルのあるべき姿
 ・ 業務ロジックと扱うデータは同じクラスにある方が良い
 ・ ドメインモデルに業務ロジックが凝集されるべき


  20. コード例 <架空アプリのユーザー仕様>
 ・ユーザー名・ユーザーIDを持つ
 ・ユーザー名は4文字以上


  21. コード例1 class User{ private String username; private String userId; public

    String getUsername(){ return this.username; } ... } <User.java>
 //フォームから受け取ったパラメータ String username = request.getParameter("username"); if(username.length() < 5) { request.setAttribute("Msg", "ユーザー名は4文字以上..."); //以下略 } <Controller.java>
 → 業務ロジックが分散する = 全容の見えないシステムになる
  22. コード例2 class User{ private Username username; private UserId userId; public

    Username getUsername(){ return this.username; } ... } <User.java>
 class Username{ private String value; public Username(String value){ if(value.length() < 5){ //処理 } } } <Username.java>
 → データとロジックがドメインモデルに凝集される = 要件が一目でわかる

  23. 3. レイヤードアーキテクチャによる関心の分離で、 
 ドメインロジックを疎結合にする


  24. レイヤードアーキテクチャとは?
 ソフトウェアシステムの関心事を切り離し、ドメイン層を他から分離する テクニック。
 → DDDでは、これ+依存関係の逆転(DI)という手法を用いて、ドメイン 層を独立させていく。


  25. レイヤードアーキテクチャによる関心の分離
 表示における関心事を扱う(UI等)
 
 <Yahoo!事例では>
 ・Controller
 ・Request(Form)
 ・Response(Resource)
 
 


  26. レイヤードアーキテクチャによる関心の分離
 ドメインオブジェクトを利用して行う処理 (CRUD処理等)の関心事を扱う
 
 <Yahoo!事例では>
 ・アプリケーションサービス
 ・Scenario
 


  27. レイヤードアーキテクチャによる関心の分離
 業務ロジック・ルールの関心事を扱う
 
 <Yahoo!事例では>
 ・ドメインモデル
 ・ドメインサービス
 ・Repositoryインターフェース
 
 


  28. レイヤードアーキテクチャによる関心の分離
 永続化テクノロジーの関心事を扱う
 
 <Yahoo!事例では>
 ・データの永続化処理
 ・外部サービスとのやりとり
 (REST API等)
 
 


  29. 依存の方向
 一般的な依存関係
 → Infrastructure層(DB処理等)を変更すると、Domain層にも影響が出る


  30. 依存の方向
 DDDでは・・・
 依存関係の逆転


  31. 依存関係の逆転(Dependency Injection)
 Domain層にRepositoryのインターフェースを置く→  Repository層がDomain層に依存する


  32. 4.リファクタリングの繰り返しからコアドメイ ンを見い だす


  33. 運用と共にモデルを改善・進化させ続ける
 リファクタリングの中で、実装がうまくいかず複雑になった部分やビジネス要求 が高いと思われる部分(コアドメインと呼ぶ)を見いだし、適切なデザインパター ンを学んで実践する


  34. DDD導入はどのような結果を
         もたらしたのか?


  35. Yahoo!事例の場合
 
  
   DDDによってビジネス要求への追従スピードは爆速になった
 


  36. Yahoo!事例の場合 <刷新前>
  ロジックが複雑で、クーポン適用ルールには誰も手をつけられなかった。
 
 <刷新後>
  DDDによってソースコードと業務知識が一体化し、チーム全員がコア部分への改 修に取り組めるようになった
 
 ※ 定量的には
   開発要望に対し、テストなど含めて約1カ月程度で行えるようになった


  37. まとめ
 DDDを正しく導入できると、エンジニアも非エンジニアも幸 せになれる・・・かも(=_=)
 


  38. 参考文献・参照ページ
 ・「ドメイン駆動設計で保守性をあげたリニューアル事例 〜 ショッピングクーポンの設計紹介」 (https://techblog.yahoo.co.jp/entry/2021011230061115/ )
 ・『ドメイン駆動設計入門』 成瀬 允宣著
 ・レイヤードアーキテクチャの視点

    (https://qiita.com/kichion/items/aca19765cb16e7e65946 )
 ・境界付けられたコンテキスト 概念編 - ドメイン駆動設計用語解説 (https://qiita.com/little_hand_s/items/2929b6323bf1bc6d0d0d )

  39. ご清聴ありがとうございました!