DDDやってみたら 実装以前の領域での学びが深かった話 くまごろー

くまごろー @kumaGoro_95 ・北海道出身 ・元公務員 ・ホテル運営会社でエンジニアやってます ・来年には北海道に帰る(決意)

3 話したいこと - ドメイン駆動設計(DDD)て何 - 私が参加しているプロジェクト - どんなことがあったか - 学び・気づき

4 ドメイン駆動設計とは(DDD) - ドメインモデル(=業務領域を表現したモデル)をソフトウェアの主役にして - コードとドメインモデルが常に一致した状態を保ち - 開発者とドメインエキスパート(業務をよく知る人)が協力し、イテレーディブにモデル の精度を上げていくことで より価値の高いアプリケーションを生み出していこうとする考え方 参考：「Domain-Driven Designのエッセンス」

5 DDDって... - 値オブジェクト・エンティティ - ドメイン層 - コンテキスト境界　 - ユビキタス言語 なんかめっちゃ小難しいイメージ 概念はなんとなく理 解したけど、実際ど んなコードになるの かな？ と思っていたら、 職場で実際にやることになった

6 どんなプロジェクトなのか - 自社業務に利用しているシステム群(顧客向け/スタッフ向け)の新規開発 - 今まではビジネス側がやりたいことがシステム制約で出来てなかった - 既存の業務が継続でき、なおかつ今後の業務改善・新しいチャレンジにも対応 できるようなシステムを開発したい - くまごろーはプラットフォーム的なプロダクトを担当するチームに所属 開発がスタートしたが。。。

7 業務要件整理は終わっていた(はずだった) 一足先に参画していたPM・先輩エンジニアが業務要件を整理していた 業務の枠組はもう整 理できてる 共有するからそれに 適合するようにモデ リングしてみて 仕様はもう決まってるみ たいだから、それにそっ てモデリングすればい いんだな 多分ドメインエキスパー トにもすぐOKもらえるは ずだから、そしたら実装 だな〜

8 最初のレビュー - ドメインエキスパートにレビューしてもらった - 私が作ったモデルは全然ダメダメだった - 対象業務の表層をなぞっただけで、現実の業務に全く対応出来てなかった - 開発者から又聞きした情報だけでは解像度が低すぎた 「xxの業務にはこう いうパターンもあっ て...」 「この料金構造だと xxx商品の料金情 報が表現出来ない なあ」 「この業務は今のシステ ムがこんな構造だからそ うしてるだけで... 本当はこうしたいんだよ ねえ」 「実は既存システ ムのx機能は、yの 用途に使ってて...」

9 FBループ地獄のはじまり - DDDの定義が頭をよぎった「ドメイン知識を深めながら反復的に深化させていく」 - これを繰り返した - どういう業務があるのかドメインエキスパートに聞く - 業務をUC単位に分けてモデリング (モブ作業多め) - ドメインエキスパートに見せる - 課題点や新情報が出てくる。話を掘り下げて業務理解を深める 「xxx」には実はこ ういうケースもあっ て... なるほど... 「xxx」というのはzzと いう意味で使われて るんですね 業務用語の意味もこの段階で認 識合わせ かくかくしかじ か その場合ってyyは どういう扱いになる んですか？

10 その結果... - モデルは最初と全然違う姿に - モデルが自然と進化し続ける感じになった - ドメインエキスパート含めたメンバー皆がシステム設計について話し合えるよう になったので、折に触れてFBがくる - 開発者が実装時に課題に気づいてモデルを更新する - 開発メンバーの誰でも実装可能な状態に(後述) - 業務自体にも色々と課題があることがわかってきた

11 見えてきた課題 - 長年やってる会社なので、業務自体に不整合があった - 業務領域と部署の区分けが一致していない(コンテキスト境界がぐちゃぐちゃ) - 既存システムの機能が不親切で、業務担当者が作業フローを魔改造して乗り 切っている(そして、魔改造したフローの上に新しい業務が成り立っている。。) 業務担当者が「システムがこ うだから」と中ば諦めていた こともわかった... システム設計の視点 で業務を観察するこ とで見えてきたこと

12 見えてきた課題 私たちが作ろうと思ってた仕組みのいくつかは、ビジネス側の課題が解決されないと無 用の長物だった - 開発のマイルストーンを更新して後回しに - それに合わせてモデルも変更。対象箇所を拡張可能な設計にしておいた →　使えない道具を無駄に作ってしまうことを回避できた そもそもの目的はシステムを 作ることじゃなく、新しい価値 を生み出すことだったな

13 実装視点では めちゃくちゃコードが描きやすくなった - 「業務的にこういうことがしたい」を理解できている - どの種類のロジックをどのレイヤーで書くかしっかり区分けされている - 詰まった時、原因が業務要件由来なのかシステム由来なのかがすぐわかる 画面表示に関するロ ジックはここ DBアクセスなどのシス テム固有のロジック ドメインオブジェクトを 使ってシステムが担当 する仕事の流れを表現 ※あくまで一例 こいつが依存の絶対的頂点 業務ルールは絶対ここに書く

14 この半年での学び・気づき - 解決したい大きな課題があって、そのアプローチとして DDDがあるんだなあ - DDDの「ドメインモデルの反復的な深化」というスタイルは課題の解像度を上げやすい。課題解決 の効果を最大化してくれる (と感じる) - 課題について皆が同じ方向を向いてないと、 DDDを取り入れても効果を発揮仕切れないかも - エンジニアがこの活動に参加することについて - 業務っていうのは千差万別なので、業務内容と現場の課題感を知れていないと良い設計はできな いなと実感 - コードを書く前に課題整理が出来ていると実装が本当に楽 - 多くの業務はシステムに根ざしているので、むしろ開発者の知見も要件定義では必要不可欠なの かも - クライアント（≒ドメインエキスパート）はお客さんではなく一緒に課題解決する仲間 - ビジネスとシステム両輪で活動を進めることで本当にやりたいことができる - 逆にいうと、DDDにはビジネスサイドとの距離の近さが必要かも

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