DDD実践のFB - Speaker Deck

Slide 1

Slide 1 text

DDD実践のFB ドメインモデリング勉強会 2019/12/18 @rirazou_ 1

Slide 2

Slide 2 text

自己紹介 • @rirazou_ • 好きな食べ物：寿司、焼き肉、ラーメン、鶏の唐揚げ • 嫌いな食べ物：パクチー • 技術的な興味：開発系は全般的に、最近は設計 • その他の興味：息子の成長 • 最近のはなし：痩せない（食ってるから） 2

Slide 3

Slide 3 text

本日のアジェンダ 3 本日お話しすること DDDの実践での問題点解決案

Slide 4

Slide 4 text

本日のアジェンダ 4 本日お話しすること DDDの実践での問題点解決案

Slide 5

Slide 5 text

本日お話しすること - モデリングというよりは実装よりの話になります - 現プロジェクトにおける簡易DDDの実践にて、特に困った問題についてお話しします - 簡易DDDよりな実践のため分析が根本的に足りてないという事はあります 5

Slide 6

Slide 6 text

本日のアジェンダ 6 本日お話しすること DDDの実践での問題点解決案

Slide 7

Slide 7 text

DDDの実践での問題点プロジェクトで何が起こったのか？ - 画面の関心毎に引っ張られ過ぎて、ドメインモデルの崩壊した。 - 集約を安易に取り扱い、巨大な集約を作ってしまい、速度面で問題になることも多かった - 速度面の改善に取り組む中で、集約を歪めてしまいさらなるドメインモデルの崩壊がおきた 7

Slide 8

Slide 8 text

DDDの実践での問題点それで何が困るのか？ - 1つのモデルが様々な関心毎を扱っている状態になり、 1つの修正がどう影響するのか読み取りずらくなった。 - 開発の後期になればなるほど、修正のコストが増加していく ※自動テストのメンテナンスも全然追いついてないのでそう言った問題点は別でありました 8

Slide 9

Slide 9 text

DDDの実践での問題点なぜそんなことが起こるのか？ - 各画面で必要な情報が異なる - 1つの画面でも複数のモデルが必要になる - 複数のモデルの属性を組み合わせて表示したりする - 画面は顧客の要求を具現化しているので、情報の組合せが複雑 9

Slide 10

Slide 10 text

DDDの実践での問題点そもそもドメインモデルが扱う事って？ - そのドメインにおけるルールなどのビジネスロジックやプロセスなどのドメインの活動そのものを扱う - ドメインの活動から発生したシステムに対する要求のユースケースをモデリングしたいわけではないユースケースに使われるドメイン活動をモデリングしたい 10

Slide 11

Slide 11 text

DDDの実践での問題点じゃあ画面が扱う事って？ - ドメインが持つ情報を最適化して表示し、人々の意思決定をサポートする - 意思決定を行った後の次のアクションへ入り口を提供し、ドメインの活動を次へと進める - 要求を満たすため、それをサポートするために存在している 11

Slide 12

Slide 12 text

DDDの実践での問題点結局は何が言いたいの？ドメインモデルは要求というよりは、要求の向こう側にあるものをモデリングしたい画面は要求そのものを実現したいドメインが持つ情報は画面と密接にかかわってはいるが、画面の関心毎とは別軸にあるものではないのか？ドメインモデルは画面から遠ざけたほうが良いのでは？もちろん、分析のスタートは要求や画面、帳票などになるが今見えているそれらをドメインだと勘違いしない方がよいのでは？ 12

Slide 13

Slide 13 text

本日のアジェンダ 13 本日お話しすること DDDの実践での問題点解決案

Slide 14

Slide 14 text

解決案 ① 戦略的設計をちゃんとやろうぜ ② CQRSをやろうぜ ※時間がないので端折りますので、知らない人は調べてください。 14

Slide 15

Slide 15 text

解決案 ① 戦略的設計をちゃんとやろうぜはい、すみません。その通りです。頑張ります。振り返ると自分が出会った問題のほとんどはドメインエキスパートを含めてドメイン自体の活動自体を分析すれば解決できたように感じています。 15

Slide 16

Slide 16 text

解決案 ② CQRSをやろうぜ CQRSとは、リードモデルとライトモデルを分けるやり方 - リードモデルは、データを読み取る操作を担当 UIの関心毎で構造化される - ライトモデルは、データを更新する操作を担当ドメインモデルの役割との相性が良い 16

Slide 17

Slide 17 text

解決案 CQRSをする上で、 - デメリットが無いわけではない - 分けることで発生する複雑さもある - 常にリードモデルとライトモデルは分ける必要はない - 素で使えるなら使えばいい - 複雑化しそうなら分ける選択肢を持つということが大事 17

Slide 18

Slide 18 text

本日のアジェンダ 18 本日お話しすること DDDの実践での問題点解決案

Slide 19

Slide 19 text

まとめ 19 - UIはドメインそのものではなく、ドメインをサポートするためのものではないのか？ - 関心毎が異なるのであれば、分けるのが良いのではないか？ - CQRSという解決策が生み出されているので、実践する場では選択肢として考慮してみては？ - 戦略的設計を頑張ります。おれ。

Slide 20

Slide 20 text

質疑応答 - 本日のアジェンダ 20 本日お話しすること DDDの実践での問題点解決案