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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

で、実際どうやってやるのか？ 

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

１．システムの関心事（＝モデル）を分析する 

Slide 10

Slide 10 text

キーワード：「関心の分離」＜商品＞  ＜配送部＞  ＜販売部＞ 

Slide 11

Slide 11 text

配送部にとっての商品・・・＜商品＞  ＜配送部＞  ・商品名  ・発送元  ・配送先  ・配送状況 

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

特定の関心事に分ける  ＜配送コンテキスト＞  ＜販売コンテキスト＞  ・商品名  ・発送元  ・配送先  ・配送状況  ・商品名  ・型番  ・売値  ・在庫数  「コンテキスト境界」と呼ぶ  「配送品」  「在庫品」 

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

参考文献・参照ページ  ・「ドメイン駆動設計で保守性をあげたリニューアル事例〜ショッピングクーポンの設計紹介」 (https://techblog.yahoo.co.jp/entry/2021011230061115/ )  ・『ドメイン駆動設計入門』成瀬允宣著  ・レイヤードアーキテクチャの視点 (https://qiita.com/kichion/items/aca19765cb16e7e65946 )  ・境界付けられたコンテキスト概念編 - ドメイン駆動設計用語解説 (https://qiita.com/little_hand_s/items/2929b6323bf1bc6d0d0d ) 

Slide 39

Slide 39 text

ご清聴ありがとうございました！ 