キッチハイク社内勉強会 ドメイン駆動設計のはなし / 2021-09-01

Transcript

1. ドメイン駆動設計のはなし
   キッチハイク社内勉強会
   2021/9/1 小川 剛
   

   View Slide

2. ● ドメイン駆動設計ってなに？
   ● DDD on Rails
   ● 私たちにできること
   本日はなすこと
   

   View Slide

3. ドメイン駆動設計ってなに？
   

   View Slide

4. ● エリック・エヴァンス「ドメイン駆動設
   計」(原著:2003)にて提唱された設計
   手法に端を発する
   ● ドメインに焦点をあてた設計手法
   ドメイン駆動設計(DDD)とは
   

   View Slide

5. ● ドメイン
   ○ 知識、影響力、または活動の領域。ユーザーがプログラムを適用する対象領
   域がソフトウェアのドメインとなる
   ● モデル(ドメインモデル)
   ○ あるドメインについて、そのうちの選択された側面を記述し、そのドメインに関
   連する問題を解決するために使うことのできる、抽象化されたシステム。
   ( https://zenn.dev/takahashim/books/fb4cdc32f8e95c より引用 )
   DDDのキー概念: ドメインとモデル
   

   View Slide

6. ● ソフトウェア化の対象となるドメインの知識を深める
   ● ドメインの知識を整理して、ドメインモデルに反映する
   ● ドメインモデルをソフトウェアに反映する
   ● これらを継続的に行っていくことでソフトウェアを設計・開発する手法であ
   る
   改めてDDDとは
   

   View Slide

7. https://www.nri.com/-/media/Corporate/jp/Files/PDF/knowledge/publication/chitekishisan/2020/09/cs20200910.pdf を参考
   DDDのサイクル
   ドメイン知識 ドメインモデル ソフトウェア
   ドメインエキスパート
   開発者
   ユビキタス言語
   

   View Slide

8. ● ドメインエキスパート
   ○ そのソフトウェアのドメインに対して、知識を持っている人
   ○ 例: 会計処理のドメインは会計担当の人が一番詳しい
   ● ユビキタス言語
   ○ ドメインモデルを中心に構造化された言語
   ○ メンバーはユビキタス言語を統一してあらゆる場所で使うようにする
   DDDのサイクル
   

   View Slide

9. ● 開発者とドメインエキスパートが対話しながら、ドメイン知識をドメインモデ
   ルに反映させ、成長させていく。
   ● このドメインモデルをソフトウェアとして実装していく
   ● ドメインモデルは関係者のドメイン知識が深まったり、またドメインが改善
   されていく中で、生き物のように変化していく
   ● したがって、ドメインモデルを更新し続けていく継続的なプロセスである
   DDDのサイクル
   

   View Slide

10. ● 開発者とドメインエキスパートが対話しながら業務知識を深めていくこと
    で、より高いレベルでソフトウェアにドメイン知識を反映していくことができ
    る
    ● ソフトウェアのドメイン知識が高凝集・疎結合であることで継続的なメンテ
    ナンス性が高まる
    DDDでどんないいことがあるの？
    

    View Slide

11. https://www.domainlanguage.com/wp-content/uploads/2016/04/Pattern-Language-Overview-med.png
    

    View Slide

12. DDDのアーキテクチャ要素
    ● たくさんある・・・
    ○ レイヤ化アーキテクチャ
    ○ 値オブジェクト
    ○ リポジトリ
    ○ エンティティ
    ○ 集約
    ○ サービス等々
    ● これらの詳細な説明は今回のスコープではないので、後の説明で出てくるもの
    だけご紹介します
    

    View Slide

13. ● アプリケーションを以下4つの層に分割する
    ○ プレゼンテーション層
    ○ アプリケーション層
    ○ ドメイン層
    ○ インフラストラクチャ層
    ● ドメイン層は、データアクセスのための技術的機
    能(インフラストラクチャ)や、ユースケースの実行
    (アプリケーション層)とは別の層に隔離されてい
    る
    レイヤ化アーキテクチャ
    https://ajlopez.wordpress.com/2008/09/12/layered-architecture-in-domain-driven-design/
    

    View Slide

14. リポジトリ
    class User
    attr_reader :id, :name, :email
    def initialize(name, email)
    # ...
    end
    # ドメインロジック
    def signup
    # ...
    end
    end
    class UserRepository
    # 永続化層へのインターフェース
    def save(user)
    # ...
    end
    end
    # ドメインオブジェクトの永続化はリポジトリ経由で行う
    userRepository.save(user)
    ● ドメインオブジェクトに対し、永続
    化層(データベース等)へのアク
    セスを提供するもの
    ● ドメインオブジェクトと永続化層
    が疎結合になる
    ● Active Recordの場合、モデル
    は永続化層(データベースの
    テーブル)をそのままラップした
    ものになる
    

    View Slide

15. ● DDDで提唱されているアーキテクチャは、総じてドメイン層 / ドメインモデ
    ルをドメインロジックのみに純化するのが目的である(と思う)
    ● ドメイン層がドメインロジックの表現のみに専念できるようにするため、責
    務の異なるものは分離する
    ● 責務の異なるものは別のドメインモデル、あるいは層に分けていく
    DDDのアーキテクチャの目的
    

    View Slide

16. DDD on Rails
    

    View Slide

17. Ruby on RailsはDDDには
    不向きと言われるけどどうなの
    

    View Slide

18. ● 静的型付け言語のほうがドメインモデルのルールを型を通じて表現しやす
    いと言われている
    ● 一方でRubyの表現力は、ドメインをコードに分かりやすく落とし込むことが
    可能である。DSLが良い例。
    ● やりやすいところもあるし、やりにくいところもあるんじゃないかなという感
    想
    RubyとDDD
    

    View Slide

19. ● Active Recordの制約
    ○ Active Recordはテーブル = エンティ
    ティを前提としている
    ○ データベースの構造がドメインの構造と
    密結合してしまう
    ○ Repositoryを介したデータアクセスがし
    づらい
    DDD on Rails
    https://bliki-ja.github.io/pofeaa/ActiveRecord/
    

    View Slide

20. ● もちろんRails自体はAR以外のORマッパーを使えるようになっている
    ● だが、現状AR一強になっているために、それ以外の強力な選択肢が少な
    い
    ● Active Recordを使うのであれば、ActiveRecordのモデルをインフラス
    トラクチャ層内に制限して、ドメイン層にモデルクラスを持たせるなどの工
    夫が必要になる
    DDD on Rails
    

    View Slide

21. ● Hanami
    ○ Clean Architectureベースのアーキテクチャ設計
    ● ROM(Ruby Object Mapper)
    ○ 上述のHanamiでも使用されているORM(公式はORMとは呼んでほ
    しくなさそう・・・)
    ○ Entity / Repositoryの分離が前提となっている
    Rails / Active Record以外の選択肢
    

    View Slide

22. こうした議論はすごく楽しいけど
    どこか違和感
    

    View Slide

23. 言語やフレームワークが
    DDDに向いている向いてないの前に
    やれることがあるんじゃないか
    

    View Slide

24. 私たちにできること
    

    View Slide

25. DDDのアーキテクチャは何のため？
    ● DDDのアーキテクチャに則っている = DDDができている、ではないはず
    ● アーキテクチャは、ソフトウェアのドメインモデルの実装を疎結合・高凝集
    にしていくためのものである
    ● RailsではDDDのアーキテクチャが適用しにくい = DDDができない、のよ
    うな短絡化を避けたいという思いもある
    

    View Slide

26. ドメイン知識 ドメインモデル ソフトウェア
    ドメインエキスパート
    開発者
    ユビキタス言語
    アーキテクチャは
    この領域の
    一部分でしかない
    

    View Slide

27. ● アーキテクチャをあれこれ話すのは楽しい・・・でもDDD全体において、そ
    れは一部分の要素でしかない
    ● よりよい設計・開発を目指すのであれば、もっと別の要素にも目を向けて
    いくべきではないのか
    ● ドメインエキスパートとどう対話していくか、ドメインをどうモデリングしてい
    くかに着目できないか
    ○ 以降では特にドメインモデリングについて触れる
    アーキテクチャ以外の領域へ
    

    View Slide

28. ドメイン知識 ドメインモデル ソフトウェア
    ドメインエキスパート
    開発者
    ユビキタス言語
    私たちは
    こちらにもっと着目すべきではな
    いか？
    

    View Slide

29. ドメインモデリングに向き合えている？
    ● モデリングのプロセスを簡略化してしまっていないか
    ● 現在のモデルに継ぎ足し継ぎ足しで考えるのが当たり前になっていない
    か
    ● それらの積み重ねの結果として、モデルの無軌道な肥大化に繋がってい
    ないだろうか
    

    View Slide

30. よりよいドメインモデリングのために
    ● DDD本では、具体的にどうドメインモデリングをすればよいかは書いてい
    ない
    ● どのようにドメインモデリングをしていけばよいか？
    

    View Slide

31. ドメイン駆動設計 モデリング / 実践ガイド
    ● とっても良い本です・・・！
    ● この本では、ユースケース図 / ドメ
    インモデル図をもとに、実装に反映
    させていくアプローチを取っている
    

    View Slide

32. 「ドメイン駆動設計 モデリング / 実践ガイド」で
    のプロセス概要
    ● モデルが解決する課題を具体化するため
    にユースケース図を起こす
    ● ドメインモデル図を起こして、集約の範囲
    や関連などを可視化する
    ● ドメインモデルを実装する
    ● 実装の知見をもとにドメインモデルを改善
    していく
    ドメインモデリングのプロセス
    

    View Slide

33. モデリングスキルのレベルアップ
    ● モデリングに対して先人がどう向き合ってきた
    か
    ● UMLモデリング、データモデリングのプロセス
    から学ぶ
    ○ 概念をいかにしてモデル化していくか
    ● 特定ユースケースにおいて定石となるモデリン
    グパターンから学ぶ
    ○ アナリシスパターン
    

    View Slide

34. ● DDDとはドメインエキスパートとの対話を通じて、ドメインモデルを深化さ
    せ、継続的に反映していくプロセスである
    ● DDDについてはアーキテクチャについつい目が行きがちであるが、それら
    はソフトウェアのドメインをいかに疎結合・高凝集にしていくための手段で
    ある
    ● ドメインをどうモデリングしていくかの技法について、私たちはまだまだ学
    ぶことがあるはず
    まとめ
    

    View Slide